Subject: [mpls-tp] Working Group Last Call on draft-ietf-mpls-tp-gach-gal-01

From: Loa Andersson <[email-masked]>
Date: Wed, 07 Jan 2009 11:06:43 +0100

All,

this is to initiate a working group last call on
http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-01

This is the first of a series MPLS Transport Profile documents
to be last called. The last call is directed to the MPLS, PWE3
and CCAMP working groups.

According to procedures agreed upon in the JWT decision the
working last call does also include the ITU-T MPLS-TP ad hoc team.

This working group last call will end eob Jan 20, 2009.

Though I know this is futile:

*Please do not do a "Replay all"* but direct comments to the
[email-masked] mailing list.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Redback Networks                      phone:  +46 8 632 77 14
An Ericsson company
                                       email:  [email-masked]
                                               [email-masked]

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 07 Jan 2009 14:28:34 +0100

Authors,

As I understand it we taken an approach that allows for a huge
amount of channel types. This means that we need to specify what
actions an LSR should take if a message received over the
associated channel have an unrecognized channel type.

Wouldn't this document be the home for that specification?

/Loa

-- 

Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 7 Jan 2009 14:39:48 +0100

Hi,
In the discussions we had in Geneva, we agreed to add an addressing TLV
to the GACH GAL document, which will support different types (e.g. IPv4,
MAC, NSAP, IPv6, etc.) in the G-ACH (between the header and the control
message). The TLV should include a src address, a dst address and an
identifier. This tupple allows the unique identification of the path
within the " addressing domain'. And it was agreed to have an optional
TLV to include also an ASCII name for the path. 
I think that this document is the right place to include these TLVs.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Loa Andersson
Sent: Wednesday, January 07, 2009 15:29
To: [email-masked]
Subject: Re: [mpls-tp] Working Group Last Call
ondraft-ietf-mpls-tp-gach-gal-01

Authors,

/Loa

-- 

Loa Andersson

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 07 Jan 2009 14:43:35 +0100

Loa,

the draft provides guidelines when the LSR does not support the GACH/GAL.
IMHO, I beleive that per message/channel type specific guidelines should
fit in the document describing the associated OAM function and/or in the
the document dealing with protocol extensions for the negotiation of the
new function.

By the way, will we really have a huge amount of channel types?

-m

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 07 Jan 2009 08:55:35 -0500

Martin,

This seems to be covered in S4, correct?
<http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-01#section-4>

In the first para of that Section:

   An LER, LSR or PE MUST discard received G-ACH packets if it is not G-
   ACH capable, if it is not capable of processing packets on the
                ^^^^^^^^^^^^^^^^^^^^
   indicated G-ACH channel, [...]

would it help to also qualify "if it is not capable, willing or
configured" in the underlined?

Thanks,

--Carlos.

-- 
-- Carlos Pignataro, DSE, CISCO
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Loa Andersson <[email-masked]>
Date: Wed, 07 Jan 2009 14:55:49 +0100

Martin,

> the draft provides guidelines when the LSR does not support the GACH/GAL.

you are right - but that is not the case I'm talking about.

the case I'm concerned about is when the GACH/GAL is supported, but the
channel type is not recognized. The compatibility section does not
entirely capture what I'm after:

    An LER, LSR or PE MUST discard received G-ACH packets if it is not G-
    ACH capable, if it is not capable of processing packets on the
    indicated G-ACH channel, or if it has not, through means outside the
    scope of this document, indicated to the sending LSR, LER or PE that
    it will process G-ACH packets received on the indicated channel.  The
    LER, LSR or PE MAY increment an error counter and MAY also optionally
    issue a system and/or SNMP notification.

The LSR I'm talking about is G-ACH capable and able to process packets
received on the associated channel.

It simply not recognizes the channel type.

As I see we could return an error message indicating the channel type;
or we could discard the packet. I've a slight preference for the first,
but could agree to either

> the document dealing with protocol extensions for the negotiation of the 

I don't see that, it would require that an implementor needs to
understand what will come in not yet published documents.
> By the way, will we really have a huge amount of channel types?

I didn't say that and I hope there will be self imposed limits from
the vendors, but I've been able to count to at least two full hands
already.

/Loa

-- 

Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Wed, 07 Jan 2009 15:02:12 +0100

Carlos,

>    ACH capable, if it is not capable of processing packets on the

see my earlier response to Martin. We maybe read the paragraph
differently, but as far as I understand it the situation where an
LSR functions perfectly well, but for a subset of the packets it
can't process them.

Maybe if you change the text to:

"if it receives packets on the indicated G-ACH channel that it can't
process"

I don't think the two sentences are semantically identical.

/Loa

-- 

Loa Andersson

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 07 Jan 2009 15:04:04 +0100

Carlos,

indeed it is, but it is a generic behaviour which is described
in this paragraph.
I understood Loa's question as per channel type specific behaviour,
explaining why I was pointing to future specific documents.

regards,
-m

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Jan 2009 15:04:24 +0100

Loa,

Different atomic functions will support different subsets of the channel
types. As such most atomic functions will ignore unexpected channel types
and forward those packets on their output. There is one exception, and that
is in adaptation sink functions. Those functions discard any unexpected
channel types.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Loa Andersson
Sent: woensdag 7 januari 2009 14:29
To: [email-masked]
Subject: Re: [mpls-tp] Working Group Last Call on
draft-ietf-mpls-tp-gach-gal-01

Authors,

As I understand it we taken an approach that allows for a huge amount of
channel types. This means that we need to specify what actions an LSR should
take if a message received over the associated channel have an unrecognized
channel type.

/Loa

Loa Andersson wrote:
> This is the first of a series MPLS Transport Profile documents to be 
> last called. The last call is directed to the MPLS, PWE3 and CCAMP 
> working groups.
> 
> According to procedures agreed upon in the JWT decision the working 
> last call does also include the ITU-T MPLS-TP ad hoc team.
> 

-- 

Loa Andersson

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Jan 2009 15:13:02 +0100

Martin,

> By the way, will we really have a huge amount of channel types?

We could limit the number of channel types for OAM by defining a channel
type "OAM", which is followed in the OAM PDU header by and OAM OpCode. I.e.
follow the well known approach in ATM OAM and Ethernet OAM.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Martin Vigoureux
Sent: woensdag 7 januari 2009 14:44
To: Loa Andersson; [email-masked]
Cc: Martin Vigoureux
Subject: Re: [mpls-tp] Working Group Last Call on
draft-ietf-mpls-tp-gach-gal-01

Loa,

the draft provides guidelines when the LSR does not support the GACH/GAL.
IMHO, I beleive that per message/channel type specific guidelines should fit
in the document describing the associated OAM function and/or in the the
document dealing with protocol extensions for the negotiation of the new
function.

-m

Loa Andersson a écrit :
> Authors,
> 
> As I understand it we taken an approach that allows for a huge amount 
> of channel types. This means that we need to specify what actions an 
> LSR should take if a message received over the associated channel have 
> an unrecognized channel type.
>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 07 Jan 2009 15:20:38 +0100

Loa,

as stated in my reply to Carlos I understood your e-mail
as being Channel Type specific, thus my answer.
We could think about having an error code as you propose below, but it
remains a generic procedure, maybe one may want to return OAM function
specific info (e.g. an OAM function might require more error codes than
this one, but that is a wild guess).
Thus I proposed that future documents deal with this specifically
in case it is needed.

As for the number of Channel Types, you are right, I misread you.

-m

Loa Andersson a écrit :
>> IMHO, I beleive that per message/channel type specific guidelines 
>> should fit in the document describing the associated OAM function 
>> and/or in the the document dealing with protocol extensions for the 
>> negotiation of the new function.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 7 Jan 2009 09:41:28 -0500

> this one, but that is a wild guess).

	Or additional information that goes with each error code.
Just look at what LSP ping/trace return. This definitely complicates  
things.

> Thus I proposed that future documents deal with this specifically

	I'd agree.

	--Tom

>>> and/or in the the document dealing with protocol extensions for  
>>> the negotiation of the new function.

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Jan 2009 16:23:53 +0100

Tom, Loa,

Let's keep things simple and consistent with other technologies. I.e. for
OAM channel types just silently discard any unexpected OAM frames entering
an MPLS-TP to XXX adaptation sink function.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Nadeau
Sent: woensdag 7 januari 2009 15:41
To: Martin Vigoureux
Cc: [email-masked]
Subject: Re: [mpls-tp] Working Group Last Call on
draft-ietf-mpls-tp-gach-gal-01

On Jan 7, 2009, at 9:20 AM, Martin Vigoureux wrote:

> Loa,
>
> as stated in my reply to Carlos I understood your e-mail as being 
> Channel Type specific, thus my answer.
> specific info (e.g. an OAM function might require more error codes 
> than this one, but that is a wild guess).

	Or additional information that goes with each error code.
Just look at what LSP ping/trace return. This definitely complicates things.

> Thus I proposed that future documents deal with this specifically in 
> case it is needed.

	I'd agree.

	--Tom

>> the case I'm concerned about is when the GACH/GAL is supported, but 
>> the channel type is not recognized. The compatibility section does 
>> not entirely capture what I'm after:
>> The LSR I'm talking about is G-ACH capable and able to process 
>> packets received on the associated channel.
>> As I see we could return an error message indicating the channel 
>> type; or we could discard the packet. I've a slight preference for 
>> the first, but could agree to either
>>>>> This is the first of a series MPLS Transport Profile documents to 
>>>>> be last called. The last call is directed to the MPLS, PWE3 and 
>>>>> CCAMP working groups.
>>>>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 07 Jan 2009 15:42:28 +0000

Nurit

I just uploaded draft-bryant-mpls-tp-ach-tlv  which proposes how this 
should work.

We need to be able to use constructs other than addesses.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 07 Jan 2009 15:47:39 +0000

> follow the well known approach in ATM OAM and Ethernet OAM.
No one is preventing sub-multiplexing within a channel, but there is 
much be gained by taking as much of the processing decision at first 
touch as is possible. This allows a single look up to identify both the 
processor than needs to action the packet, queue policy etc etc.

Doing this in more than one stage in the fast path just wastes silicon 
that is better employed on port density, forwading speed, or just kept 
quiet to avoid wasting power.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 07 Jan 2009 15:50:41 +0000

> an MPLS-TP to XXX adaptation sink function.
Maarten first priority is to keep things simple and consistent with MPLS.

Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 7 Jan 2009 11:27:55 -0500

> Maarten first priority is to keep things simple and consistent with  

	Agreed. For my perspective, the latter is paramount.

	--Tom

---

From: Dieter Beller <[email-masked]>
Date: Wed, 07 Jan 2009 17:30:49 +0100

Hi all,

this is just to let you know that Adrian and myself are working on a
draft

requesting 2 further G-ACH channel types:

xx   Management Communication Channel

yy   Signaling Communication Channel

In this context it is also necessary to indicate what PDU type the
MCC/SCC

G-ACH is carrying (IPv4, IPv6, CLNP, etc.).

Cheers,

Dieter

Stewart Bryant wrote:

Nurit

Stewart

Hi,

to the GACH GAL document, which will support different types (e.g.
IPv4,

TLV to include also an ASCII name for the path. I think that this
document is the right place to include these TLVs.

Best regards,

Nurit

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

To: [email-masked]

Authors,

/Loa

Loa Andersson wrote:

All,

/Loa

mpls-tp mailing list

[email-masked]

--

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 07 Jan 2009 16:40:59 +0000

Dieter Beller wrote:
> Hi all,
>
> this is just to let you know that Adrian and myself are working on a draft
> In this context it is also necessary to indicate what PDU type the MCC/SCC
So what meta data do you want between the end of the ACH and the start 
of your payload?

Stewart

> ------------------------------------------------------------------------

---

From: Dieter Beller <[email-masked]>
Date: Wed, 07 Jan 2009 17:59:12 +0100

Hi Stewart,

Stewart Bryant wrote:

Dieter
Beller wrote:

Hi all,

A payload type identifier field as we briefly discussed in Geneva. Do
you have

another suggestion?

Cheers,

Dieter

Stewart

Cheers,

Dieter

Stewart Bryant wrote:

Nurit

Stewart

Hi,

Best regards,

Nurit

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

To: [email-masked]

Authors,

/Loa

Loa Andersson wrote:

All,

/Loa

mpls-tp mailing list

[email-masked]

--

mpls-tp mailing list

[email-masked]

--

---

From: Dieter Beller <[email-masked]>
Date: Wed, 07 Jan 2009 18:02:47 +0100

Hi Stewart,

Stewart Bryant wrote:

Dieter
Beller wrote:

Hi all,

another suggestion?

Cheers,

Dieter

Stewart

Cheers,

Dieter

Stewart Bryant wrote:

Nurit

Stewart

Hi,

Best regards,

Nurit

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

To: [email-masked]

Authors,

/Loa

Loa Andersson wrote:

All,

/Loa

mpls-tp mailing list

[email-masked]

--

mpls-tp mailing list

[email-masked]

--

---

From: "David Allan" <[email-masked]>
Date: Wed, 7 Jan 2009 13:08:35 -0500

Hi Loa/authors: 

Some comments:

1) I for one would like to see a stronger health warning in section 3.1.
Such as...

"You MAY use these mechanisms with IP/MPLS but will produce
indeterminate results as GAL/GACH identified OAM PDUs are not guaranteed
to fate share with payload in the presence of ECMP (as per RFC 4928)."

Alternatively I'd recommend a stronger advistory recommending that these
tools should only be considered when one can be sure that there is an
identical profile to MPLS-TP employed with IP/MPLS (no ECMP, no PHP, no
merge).  

2) Similarly section 3.3 suggests that the presence of the GACH means
the GAL/GACH combination complies with RFC 4928.

Presence of the GACH alone avoids ECMP and v4/v6 aliasing. Not true for
the combination of GAL/GACH.

So the first bullet of 3.3 should simply be turfed. The claim of 4928
compliance is specious and misleading.

3) The second bullet of 3.3 (suggesting scope of GAL exceeds that of RFC
3429) does not really hold water as well and should also be turfed.

The only real substantive content in section 3.3 is that RFC 3429 is
deployed and the hence a new reserved label was needed if OAM PDUs were
to be redesigned.

4) I find section 4 a bit bizzare, suggesting what non compliant devices
should do....
	- either it does not support GAL/GACH and does not know it OR
	- it does not support it but knows what it is...

   What it should say is already in RFC 3813....increment
ifInUnknownProtos in the MPLS layer ifTable.

Cheers
Dave

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Jan 2009 18:28:57 -0000

Hi,

Here are some observations...

Cheers,
Adrian

===
idnits

It would be nice if you ran idnits before asking for last call so
that we don't have to spot those issues

===

Header
s/MPLS/Network Working Group/

===

General terminology

I don't think that the term "MPLS section" is familiar to your
readers. Therefore, you should explain it where it is first used
both in the Abstract and in the Introduction (without the reader
having to hunt out the Terminology section).

===

Abstract
s/also assigns of one of/also assigns one of/

===

Acronyms.

You need to expand acronyms on first use. (You can't inherit the
expansions from the Abstract.)
I see...
  LSR
  T-PE
  S-PE
  LSP
  PW
  PSN
  TTL

===

"proposal" language

Several times you "propose" things. Given that you are writing a
document you hope will be a definitive standard, I suggest you
change "propose" to "define" through the document.

===

Introduction - bottom of page 4

You have

   This
   document proposes an OPTIONAL mechanism that is RECOMMENDED for
   identifying and demultiplexing MPLS OAM and other maintenance
   messages when IP based mechanisms such as those in [4] and [3] are
   not available.

I think this 2119 language is slightly confused. Why not say...

   This
   document defines a mechanism that is RECOMMENDED for identifying and
   demultiplexing MPLS OAM and other maintenance messages when IP-based
   mechanisms such as those in [4] and [3] are not available. The
   mechanisms MAY also be used in addition to IP-based mechanisms.

===

Introduction

s/maintenace/maintenace/

===

Section 1.2.

s/(ACH) ./(ACH)./

===

Use of the wrong tense.
For example, in Section 2...

   The use of the CC Type 1, currently limited to MPLS PWs, is here
   extended to apply to MPLS LSPs as well as to MPLS Sections.

s/currently/previously/

===

Section 2

s/(G- ACH)/(G-ACH)/

===

Section 2

   The PWE3 control word MUST be present in the
   encapsulation of user packets when the G-ACH is used to demultiplex
   the associated channel packet on a PW.

I'm a little confused, but perhaps s/demultiplex/multiplex/

===

Section 2

   This draft allocates Bit
   8 of the ACH to the ACH TLV bit.  This bit is set to 1 to indicate
   that an object defined in the ACH TLV registry immediately follows
   the G-ACH, otherwise it is set to 0.  Bits 8 to 14 of the G-ACH are
   reserved and MUST be set to 0..

That would be bits 9 to 14?

Can you please include a reference to the ACH TLV registry? I have
looked on the IANA pages, but can't find it. Perhaps you mean to
create the registry in this document? If so, you need to describe
how the TLVs are carried and formed, and how the Type fields are
allocated (IETF consensus?). I don't think you can defer defining
the registry to another document because that would make the A-bit
meaningless.

===

Section 3.1

   These alert mechanisms SHOULD preferably be used in non MPLS-TP
   environments.

s/SHOULD preferably/SHOULD/

===

Section 3.2

   The 'Generic Associated channel header Label (GAL)' MUST only be used
   with Label Switched Paths (LSPs), with their associated Tandem
   Connection Monitoring Entities (see [17] for definitions of TCMEs)
   and with MPLS Sections.

I think that the use of MUST means that [17] needs to be a normative
reference. You may avoid this by:
- including the definition of a TCME here, with a reference to [17]
  for more information
or
- leaving out the term completely, falling back to "a segment of a
  MPLS LSP that is being monitored"

===

Section 3.2

   The GAL applies to both P2P and P2MP LSPs, unless otherwise stated.

You are silent about multi-access links that form MPLS Sections.

===

Section 3.2.1.1

   With regards to the MPLS Section, both LERs are Maintenance End
   Points (see [17] for definitions of MEPs).

s/LERs/LSRs/?

===

Section 3.2.1.1

   o  The TTL field of the GAL SHOULD be set to 1.

You say "SHOULD be set to 1" and that clearly allows "MAY be set to 0".
Can you give the use case for set to zero?

===

Section 3.2.1.1

   The maintenance packet, the G-ACH and the GAL SHOULD NOT be modified
   towards the tail-end LSR (Z).  Upon reception of the labelled packet,
   the tail-end LSR (Z), after having checked the GAL fields, SHOULD
   pass the whole packet to the appropriate processing entity.

I think you need two instances of...
s/maintenance packet/maintenance message/

===

Section 3.2.1.2

   Note that it is possible that the LSP MAY also be tunnelled in
   another LSP (e.g. if a MPLS Tunnel exists between B and C), and as
   such other labels MAY be present above it in the label stack.

"above it"?

===

Section 3.2.1.2

   To send a maintenance packet on the LSP associated channel, the head-
   end LSR (A) generates a OAM message with a G-ACH on which it first
   pushes a GAL followed by the LSP label.

s/maintenance packet/maintenance message/

===

Section 3.2.1.2

Please suggest how to set the TC bits.

===

Section 3.2.1.2

   o  The TTL field of the GAL SHOULD be set to 1.

Ditto the use of "SHOULD"

===

Section 3.2.1.2

   o  The S bit of the GAL SHOULD be set to 1 in MPLS-TP.

A couple of points...

1. You need

   o  The S bit of the LSP Label MUST NOT be set to 1 in MPLS-TP.

2. Why do you have "SHOULD"? That would allow a label stack that
   ends without the S bit set.

===

Section 3.2.1.2

   The maintenance message, the G-ACH or the GAL SHOULD NOT be modified
   towards the targeted destination.  Upon reception of the labelled
   packet, the targeted destination, after having checked both the LSP
   label and GAL fields, SHOULD pass the whole packet to the appropriate
   processing entity.

s/pass the whole packet/pass the whole maintenance message/

===

Section 3.2.1.3

   Tandem Connection Monitoring will be specified in a separate
   document.

I think this is a dodge :-)

The processing rules you have written for the two other cases are not so
complicated. I think you should cover the case here as well.

===

Section 3.3

s/wth/with/

===

Section 4

There has already been discussion on the list about backward
compatibility. You need to handle several cases. It would be helpful
to list the cases and state the expected behavior with references to
existing FC

- GAL is uncovered and not understood.
  This is a legacy issue.
- GAL is uncovered and understood, but the receiver declines to process.
  Could be handled using legacy behavior, or new behavior.
- GAL is uncovered and understood, but cannot be processed at the
  moment.
  New behavior.
- GAL is uncovered, but the S-bit is clear.
  New behavior.
- GAL is uncovered, but the next eight bits are not 0b00010000.
  That is, must have CC type 1, version 0.
  New behavior, but can maybe fall back on legacy treatment of the ACH
- A-bit is set, but receiver does not wish to process any TLVs.
  New behavior.
- Channel Type not understood.
  New behavior, but can maybe fall back on legacy treatment of the ACH
- Channel Type understood, but not supported.
  New behavior, but can maybe fall back on legacy treatment of the ACH
- Experimental Channel Type not understood.
  New behavior.
- ACH TLV type not understood.
  New behavior.
- ACH TLV type understood, but not supported.
  New behavior.
- ACH TLV malformed
  New behavior.

You do cover some of these, but the description is not so clear.

===

Section 4

   ACH capable

When you say "received", I think you mean that all of the labels above
the GAL have been popped.

===

Section 5

   The congestion considerations detailed in RFC 5085 [2] apply.
   Further generic associated channel-specific congestion considerations
   will be detailed in a future revision of this document.

What future revision? You have requested last call!

===

Section 6
s/Security Consderations/Security Considerations/

===

Section 6

If you can successfully get this 2.5 line Security Considerations
section through the IESG without any additions I will be really
surprised.

At the very least, you have introduced a change with the experimental
CC Types that allows scope for attacks.

===

Section 7

s/in[13]/in [13]/

===

Section 7

   However, a requirement has emerged (see [16]) to allow for
   optimizations or extensions to OAM and other control protocols
   running in an associated channel to be experimented with without
   resorting to the IETF standards process, by supporting experimental
   code points.

This definitely makes [16] a normative reference.

===

Section 7

   32752 - 32767 : Experimental

This is far too many experimental code point. Please see RFC 3692
section 1.1 that suggests that in most cases a *single* experimental
code point is enough, and that multiple codepoints may be risky.

   Code points in the experimental range MUST be used according to the
   guidelines of RFC 3692 [14].  Experimental OAM functions MUST be
   disabled by default.  The channel type value used for a given
   experimental OAM function MUST be configurable, and care MUST be
   taken to ensure that different OAM functions that are not
   interoperable are configured to use different channel type values.

This is precisely the point! The intention is not to allow a situation
where deployments use multiple different experimental channel types.

===

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 08 Jan 2009 12:59:37 +0100

MPLS-TP is a transport profile and will be managed as a transport network
(aka SDH like network management). As such there is a requirement to behave
in this case like other transport network technologies behave.

Regards,
Maarten 

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: woensdag 7 januari 2009 17:28
To: [email-masked]
Cc: Maarten Vissers; 'Martin Vigoureux'; [email-masked]
Subject: Re: [mpls-tp] Working Group Last Call on

On Jan 7, 2009, at 10:50 AM, Stewart Bryant wrote:

>> OAM channel types just silently discard any unexpected OAM frames 
>> entering an MPLS-TP to XXX adaptation sink function.
>>
>> Regards,
>> Maarten
>>
>>

	--Tom

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 07 Jan 2009 14:41:58 +0100

Loa,

-m

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 12 Jan 2009 10:23:33 +0100

I think that:

1) we all agree that we must keep things simple

2) Maarten is right that we must allow consistency with other transport
technologies to allow deployment of MPLS-TP within transport networks

3) Stewart and Tom are right that we must allow consistency with
existing IP/MPLS networks to allow deployment of the new features within
IP/MPLS networks

I think that the solution described in section 4 of the draft fullfills
all the three objectives stated above.

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Thursday, January 08, 2009 1:00 PM
> To: 'Thomas Nadeau'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Working GroupLast Call on

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 15 Jan 2009 18:50:41 +0000

Colleagues,

I will split my comments on draft-ietf-mpls-tp-gach-gal-01 into two e-mails,
one on terminology (this one) and one with the rest of my comments which I
think will be relatively easy for the WG to agree/not agree to.

The GAL/GACH draft uses a number of terms including LSP, MPLS Section and
Tandem Connection Monitoring Entity when talking about it's applicability &
use.  I think this is problematical for two reasons (1) the relationship
between these entities is not explained and (2) Section and Tandem
Connection Monitoring Entity (TCME) are will be new terms to many readers.
Note: I believe the explanation of the relationship between these terms does
not fit into the GAL/GACH draft but into the other requirements/rosetta
stone/solution drafts.

Furthermore I believe these multiple terms are unnecessary.  The general
case where the GAL/GACH is applicable is to all MPLS segments where segment
is defined as 

   Segment: A segment is a single resource or a set of cross-connected
   resources that constitutes part of a path.  A segment may be a single
   link (hop) within a path, a series of adjacent links (hops) within a
   path, or the entire end-to-end-path.

I believe such a definition covers LSPs, TCMEs and MPLS Sections.

An MPLS Section can be considered a special case of a segment where the GAL
is both top & bottom of stack (i.e. There is no MPLS forwarding label
between the GAL and the server layer).

So really the only terminology that needs to be used within the document is
(MPLS/LSP/PW as appropriate) segment. The authors may want to use "MPLS LSPs
and segments" to emphasise that it is applicable to End to End LSPs as well
as segments (which are often incorrectly thought of as referring to only
part of a path)

Thoughts?

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 15 Jan 2009 18:56:55 +0000

My other LC comment on draft-ietf-mpls-tp-gach-gal-01 follows (when I came
to review the draft it appears I don't have as many comments as I first
thought).

Section 3.2.  Is it worth explicitly stating in this section that the GAL
must be followed by a GACH.  This is implicit from Section 3 but as Section
3.2 lists some MUSTs and MUST NOTs related to the use & applicability of the
GAL it might be worth explicitly mentioning it here also.

Ben

---

From: <[email-masked]>
Date: Thu, 15 Jan 2009 19:10:11 -0000

Thanks Ben...just one remark (snipped to it)

Ben Niven-Jenkins wrote 15 January 2009 18:51
> An MPLS Section can be considered a special case of a segment 
> where the GAL is both top & bottom of stack (i.e. There is no 
> MPLS forwarding label between the GAL and the server layer).

This is a really important point, as this (ie label 13 with no lower
level of labelling) uniquely identifies the specific case of a
link-connection in the logically OOB CP/MP network.  Still not sure we
should call it a 'section' but I'm not overly concerned about the
terminology as long as the functions are right.

regards, Neil

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 15 Jan 2009 12:01:02 -0800

Sounds good 

>From: Ben Niven-Jenkins [mailto:[email-masked]] 
>Sent: Thursday, January 15, 2009 10:51 AM
>To: [email-masked]
>Subject: Re: [mpls-tp] [mpls] Working Group Last Call 
>I will split my comments on draft-ietf-mpls-tp-gach-gal-01 
>into two e-mails, one on terminology (this one) and one with 
>the rest of my comments which I think will be relatively easy 
>for the WG to agree/not agree to.
>
>The GAL/GACH draft uses a number of terms including LSP, MPLS 
>Section and Tandem Connection Monitoring Entity when talking 
>about it's applicability & use.  I think this is problematical 
>for two reasons (1) the relationship between these entities is 
>not explained and (2) Section and Tandem Connection Monitoring 
>Entity (TCME) are will be new terms to many readers.
>Note: I believe the explanation of the relationship between 
>these terms does not fit into the GAL/GACH draft but into the 
>other requirements/rosetta stone/solution drafts.
>
>Furthermore I believe these multiple terms are unnecessary.  
>The general case where the GAL/GACH is applicable is to all 
>MPLS segments where segment is defined as 
>
>So really the only terminology that needs to be used within 
>the document is (MPLS/LSP/PW as appropriate) segment. The 
>authors may want to use "MPLS LSPs and segments" to emphasise 
>that it is applicable to End to End LSPs as well as segments 
>(which are often incorrectly thought of as referring to only 
>part of a path)
>
>Thoughts?
>
>Ben
>
>

---

From: George Swallow <[email-masked]>
Date: Thu, 15 Jan 2009 15:07:11 -0500

I support these changes.  Simplifying terminology adds clarity to the
document.

...George

---

From: Keng Lim <[email-masked]>
Date: Thu, 15 Jan 2009 16:10:02 -0500

I support the changes proposed by Ben for greater clarity to the doc. 

> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: Thursday, January 15, 2009 1:51 PM
> To: [email-masked]
> about it's applicability & use.  I think this is 
> problematical for two reasons (1) the relationship between 
> these entities is not explained and (2) Section and Tandem

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 15 Jan 2009 16:20:08 -0500

Support-

-----Original Message-----
Behalf Of Ben Niven-Jenkins

Colleagues,

I will split my comments on draft-ietf-mpls-tp-gach-gal-01 into two
e-mails,
one on terminology (this one) and one with the rest of my comments which
I
think will be relatively easy for the WG to agree/not agree to.

The GAL/GACH draft uses a number of terms including LSP, MPLS Section
and
Tandem Connection Monitoring Entity when talking about it's
applicability &
use.  I think this is problematical for two reasons (1) the relationship
between these entities is not explained and (2) Section and Tandem
Connection Monitoring Entity (TCME) are will be new terms to many
readers.
Note: I believe the explanation of the relationship between these terms
does
not fit into the GAL/GACH draft but into the other requirements/rosetta
stone/solution drafts.

Furthermore I believe these multiple terms are unnecessary.  The general
case where the GAL/GACH is applicable is to all MPLS segments where
segment
is defined as 

An MPLS Section can be considered a special case of a segment where the
GAL
is both top & bottom of stack (i.e. There is no MPLS forwarding label
between the GAL and the server layer).

So really the only terminology that needs to be used within the document
is
(MPLS/LSP/PW as appropriate) segment. The authors may want to use "MPLS
LSPs
and segments" to emphasise that it is applicable to End to End LSPs as
well
as segments (which are often incorrectly thought of as referring to only
part of a path)

Thoughts?

Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 15 Jan 2009 16:22:27 -0500

Support. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: 15 January 2009 16:20
To: Ben Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last
Callondraft-ietf-mpls-tp-gach-gal-01

Support-

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

Colleagues,

I will split my comments on draft-ietf-mpls-tp-gach-gal-01 into two
e-mails, one on terminology (this one) and one with the rest of my
comments which I think will be relatively easy for the WG to agree/not
agree to.

The GAL/GACH draft uses a number of terms including LSP, MPLS Section
and Tandem Connection Monitoring Entity when talking about it's
applicability & use.  I think this is problematical for two reasons (1)
the relationship between these entities is not explained and (2) Section
and Tandem Connection Monitoring Entity (TCME) are will be new terms to
many readers.
Note: I believe the explanation of the relationship between these terms
does not fit into the GAL/GACH draft but into the other
requirements/rosetta stone/solution drafts.

segment is defined as 

An MPLS Section can be considered a special case of a segment where the
GAL is both top & bottom of stack (i.e. There is no MPLS forwarding
label between the GAL and the server layer).

So really the only terminology that needs to be used within the document
is (MPLS/LSP/PW as appropriate) segment. The authors may want to use
"MPLS LSPs and segments" to emphasise that it is applicable to End to
End LSPs as well as segments (which are often incorrectly thought of as
referring to only part of a path)

Thoughts?

Ben

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 15 Jan 2009 17:20:23 -0500

Support as well.

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 16 Jan 2009 09:37:28 +0100

Terminology simplicifaction is a splendid idea. But before we start doing this we might want to have a look at a number of other drafts as well such as the OAM framework draft. The terminology needs to be consistent across these drafts. In other words, if there is a convincing need to have this distinction (and I am not sure there is one, will have a look at that again) then it would be good to converge on a terminology which is sensible across the collection of MPLS-TP drafts. Having that said, I still think terminology simplification is splendid.

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Sent: Thursday, January 15, 2009 7:51 PM
> To: [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 16 Jan 2009 10:14:54 +0100

Hello Rolf,

You wrote:

> Terminology simplicifaction is a splendid idea. But before we start
> doing this we might want to have a look at a number of other drafts
> as well such as the OAM framework draft. The terminology needs to be
> consistent across these drafts. In other words, if there is a
> convincing need to have this distinction (and I am not sure there is
> one, will have a look at that again) then it would be good to
> converge on a terminology which is sensible across the collection of
> MPLS-TP drafts.

That was one of the reasons to start the drat Roseetta stone.
A single draft that contains all terms in the mpls-tp drafts
which also links the terminology used by IETF and ITU-T.

> Having that said, I still think terminology
> simplification is splendid.

I agree.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Fri, 16 Jan 2009 09:25:35 -0000

Colleagues,
Huub van Helvoort wrote 16 January 2009 09:15
> > doing this we might want to have a look at a number of 
> other drafts as 
> > well such as the OAM framework draft. The terminology needs to be 
> > one, will have a look at that again) then it would be good 
> to converge 
> > on a terminology which is sensible across the collection of MPLS-TP 
> > drafts.
> 
I agree.  I think the work that is being done in G.800 (unified
modelling of networks) is particularly important and where possible we
should try and seek alignment with both the concepts and termonology
that is used in this.

regards, Neil

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 16 Jan 2009 12:25:55 +0100

Huub,

I think the rosetta stone draft is important. What I would like to avoid, and I am sure this is easily achievable, to have one draft that refers to a segment being A, B and C and another draft excluding C and the rosetta stone draft will be of very little help then. But again, this is not hard we just need to be clear about this.

Best,

	Rolf

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Friday, January 16, 2009 10:15 AM
> To: [email-masked]
> Subject: Re: [mpls-tp] [mpls] Working Group LastCall 
> > Having that said, I still think terminology simplification is 
> > splendid.
> 
> I agree.
> 
> Cheers, Huub.
> 
> --

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 16 Jan 2009 13:56:19 +0100

Neil,

I think this is an important point as I think G.800 and IETF terminology sometimes clash. A subnetwork is e.g. is something very different depening on which kind of community you are asking. I would therefore very much prefer to not "invent" new terms so that we end up confusing two communities. I am saying this just now, as I know of incindences where these things have happened and I'd like to avoid that.

Best,

	Rolf

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, January 16, 2009 10:26 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [mpls] Working GroupLastCall 
> > A single draft that contains all terms in the mpls-tp drafts which 
> > also links the terminology used by IETF and ITU-T.
> > 
> I agree.  I think the work that is being done in G.800 
> (unified modelling of networks) is particularly important and 
> where possible we should try and seek alignment with both the 
> concepts and termonology that is used in this.
> 
> regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 16 Jan 2009 14:03:28 +0000

Rolf,

I understand your concern. I think a way forward is for all drafts to refer
to (MPLS/LSP/PW as appropriate) segments. Somewhere in the terminology
definitions we can clarify that for e.g. A Tandem Connection Maintenance
Entity is equivalent to an LSP segment.

We can then remove section and TCME from all drafts except possibly in a few
places where their use is required to explain a specific corner case
(although I expect the number of these to be low).

Ben

On 16/01/2009 11:25, "Rolf Winter" <[email-masked]> wrote:

> Huub,
> 
> I think the rosetta stone draft is important. What I would like to avoid, and
> I am sure this is easily achievable, to have one draft that refers to a
> segment being A, B and C and another draft excluding C and the rosetta stone
> draft will be of very little help then. But again, this is not hard we just
> need to be clear about this.
> 
> Best,
> 
> Rolf
> 
>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 16 Jan 2009 11:30:53 -0500

Suggest to re-organize the sentences a bit in this section to smooth
(and incorporate Ben's comment), how about:

Change from:
----

   In MPLS-TP, the GAL MUST always be at the bottom of the label stack
   (i.e.  S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear within
   the label stack.

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, the GAL MUST only appear once in
   the label stack for packets on the generic associated channel.
---
To:
----
The 'Generic Associated channel header Label (GAL)' MUST be used
   for Label Switched Paths (LSPs) and LSP Segments to indicate the
presence of a packet
containing a GACH.
Furthermore, the GAL MUST only appear once in
   the label stack for generic associated channel packets.

   In MPLS-TP, the GAL MUST always be at the bottom of the label stack
   (i.e.  S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear within
   the label stack.

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  

-----Original Message-----
Sent: Thursday, January 15, 2009 1:57 PM

My other LC comment on draft-ietf-mpls-tp-gach-gal-01 follows (when I
came
to review the draft it appears I don't have as many comments as I first
thought).

Section 3.2.  Is it worth explicitly stating in this section that the
GAL
must be followed by a GACH.  This is implicit from Section 3 but as
Section
3.2 lists some MUSTs and MUST NOTs related to the use & applicability of
the
GAL it might be worth explicitly mentioning it here also.

Ben

---

From: Dieter Beller <[email-masked]>
Date: Fri, 16 Jan 2009 18:11:57 +0100

Hi Deborah,

I have no problem with your change proposal. But, please keep in mind
that

the GAL/GACH can be used as management communication channel and as

signaling communication channel that is NOT associated with an LSP,
i.e., the

GAL is the top of stack and bottom of stack at the same timein this
case.

draft-ietf-mpls-tp-gach-gal-01should not preclude this.

A new I-D is in preparation that provides the details and we intend to
submit

it in the coming days.

Cheers,

Dieter

BRUNGARD, DEBORAH A, ATTLABS wrote:

Change from:
----

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

Ben

All,

/Loa

--

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 16 Jan 2009 12:20:08 -0500

Hi Dieter,

My suggestions were based on the current text - can you suggest how to
reword?  I'm not the editor;-).

Deborah

From: Dieter Beller [mailto:[email-masked]] 
Sent: Friday, January 16, 2009 12:12 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: Ben Niven-Jenkins; [email-masked]; 'Adrian Farrel'
Subject: Re: [mpls-tp] [mpls] Working Group Last Call
ondraft-ietf-mpls-tp-gach-gal-01

Hi Deborah,

Cheers,
Dieter

 
Change from:
----

 

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

 
Ben

On 07/01/2009 10:06, "Loa Andersson" <[email-masked]> <mailto:[email-masked]>
wrote:

	All,

	 
	According to procedures agreed upon in the JWT decision the
	working last call does also include the ITU-T MPLS-TP ad hoc
team.

	 
	 
	/Loa

 

-- 

________________________________

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 16 Jan 2009 18:28:03 +0100

Deborah,

I guess Dieter's e-mail was referring to the fact that,
in the proposed reshaped first paragraph,
the applicability of GAL to MPLS Sections disappeared.

This paragraph is anyway being re-edited.

thx
-m

BRUNGARD, DEBORAH A, ATTLABS a écrit :
> Hi Dieter,
> 
>  
> 
> My suggestions were based on the current text – can you suggest how to 
> reword?  I’m not the editor;-).
> 
> Deborah
> 
>  
> 
> *From:* Dieter Beller [mailto:[email-masked]]
> *Sent:* Friday, January 16, 2009 12:12 PM
> *To:* BRUNGARD, DEBORAH A, ATTLABS
> *Cc:* Ben Niven-Jenkins; [email-masked]; 'Adrian Farrel'
> *Subject:* Re: [mpls-tp] [mpls] Working Group Last Call 
> I have no problem with your change proposal. But, please keep in mind that
> GAL is the top of stack and bottom of stack at the same timein this case.
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On
> 
> To: [email-masked] <mailto:[email-masked]>
> 
> On 07/01/2009 10:06, "Loa Andersson" <[email-masked]> <mailto:[email-masked]> wrote:
> 
>  
> 
>   
> 
>     All,
> 
>      
> 
>     [email-masked] <mailto:[email-masked]> mailing list.
> 
>      
> 
>     /Loa
> 
>         
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: Dieter Beller <[email-masked]>
Date: Fri, 16 Jan 2009 18:32:34 +0100

Hi Martin and Deborah,

Martin Vigoureux wrote:

Deborah,

exactly.

You may write something like:

The GAL MAY also provide a channel in its own right without being
associated with an LSP for providing management or control plane
communication across a link interconnection 2 LSRs. In this case,
the GAL is the only label of the label stack.

Just my 2c.

Cheers,

Dieter

thx

-m

Hi Dieter,

Deborah

Hi Deborah,

it in the coming days.

Cheers,

Dieter

Change from:

----

and with MPLS Sections.

the label stack.

---

To:

----

presence of a packet

containing a GACH.

the label stack.

user-plane packets.

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

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On

came

thought).

GAL

Section

3.2 lists some MUSTs and MUST NOTs related to the use &
applicability of

the

Ben

On 07/01/2009 10:06, "Loa Andersson" <[email-masked]>
<mailto:[email-masked]> wrote:

All,

/Loa

mpls-tp mailing list

mpls-tp mailing list

--

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

--

---

From: <[email-masked]>
Date: Fri, 16 Jan 2009 18:05:38 -0000

Your last para Dieter is the critical one, ie:

This is how we can provide the OOB CP/MP and avoid running raw IP.  Might be worth also noting that this is actually a link connection between 2 logically adjacent nodes at layer N.  When we solve the MPLS-TPoverMPLS-TP client/server requirement we will still have this same (bottom of stack GAL) logical link connection requirement for the CP/MP, ie a link connection (ie single hop) at layer N-1 will be formed by a multi-hop LSP *DP* connection in layer N.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Beller
	Sent: 16 January 2009 17:33
	To: Martin Vigoureux
	Cc: [email-masked]
	Subject: Re: [mpls-tp] [mpls] WorkingGroup Last Call ondraft-ietf-mpls-tp-gach-gal-01

	Hi Martin and Deborah,
	
	Martin Vigoureux wrote: 

		Deborah, 

	exactly.

	Just my 2c.

	Cheers,
	Dieter

		thx 
		-m 

			Hi Dieter, 

			My suggestions were based on the current text - can you suggest how to reword?  I'm not the editor;-). 
			
			Deborah 

			*Subject:* Re: [mpls-tp] [mpls] Working Group Last Call ondraft-ietf-mpls-tp-gach-gal-01 

			Hi Deborah, 
			
			signaling communication channel that is NOT associated with an LSP, i.e., the 
			
			A new I-D is in preparation that provides the details and we intend to submit 
			it in the coming days. 

			Cheers, 
			Dieter 

			

			Change from: 
			
			---- 

			
			
			   and with MPLS Sections. 

			

			
			   the label stack. 

			

			--- 
			
			To: 
			
			---- 

			
			presence of a packet 
			
			containing a GACH. 

			

			

			   the label stack. 

			
			   user-plane packets.  

			-----Original Message----- 
			
			From: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>  [mailto:[email-masked]] On 

			
			To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>  

			
			
			came 

			thought). 

			
			GAL 

			Section 

			the 

			
			Ben 

			  
			
			On 07/01/2009 10:06, "Loa Andersson" <[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> <mailto:[email-masked]>  wrote: 

			  
			    All, 

			

			

			
			    [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>  mailing list. 

			    /Loa 

			
			
			mpls-tp mailing list 
			
			[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>  

			
			mpls-tp mailing list 
			
			[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>  

			

			-- 

			

	--

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 16 Jan 2009 18:20:23 +0000

Applicability of GAL to MPLS Sections disappears because MPLS Section is
just a special case of an LSP segment (my original proposal). So MPLS
sections are covered in the first paragraph when it says "LSP Segments" (as
are Tandem Connections which are also just LSP segments).

Ben

On 16/01/2009 17:28, "Martin Vigoureux"
<[email-masked]> wrote:

>> My suggestions were based on the current text  can you suggest how to
>> reword?  I¹m not the editor;-).
>> 
>> Deborah
>> 
>>  
>>

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 16 Jan 2009 11:38:48 -0800

Support.

Thanks
Nitin

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 17 Jan 2009 10:14:31 +0100

Dieter,
 
If we consider the Section as an "Unlabelled LSP", then it is not necessary
to make an exception.
 
Note that a Section signal may be carried through a Carrier-Carrier network
as a service signal, in which case it will be labelled and treated as an
LSP; i.e. the Unlabelled-LSP is forwarded in the Carrier-Carrier network as
a Labelled-LSP. As the Section signal is the only "LSP" on the interface it
can be carried without a label. Note that this is similar with the Section
VLAN in Ethernet; this VLAN can be carried as Untagged VLAN over the
interface (or as Priority-Tagged VLAN).
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dieter Beller
Sent: vrijdag 16 januari 2009 18:33
To: Martin Vigoureux
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last
Callondraft-ietf-mpls-tp-gach-gal-01

Hi Martin and Deborah,

Martin Vigoureux wrote: 

Deborah, 

exactly.

Just my 2c.

Cheers,
Dieter

thx 
-m 

Hi Dieter, 

Deborah 

Hi Deborah, 

signaling communication channel that is NOT associated with an LSP, i.e.,

Cheers, 
Dieter 

Change from: 

---- 

   and with MPLS Sections. 

   the label stack. 

--- 

To: 

---- 

presence of a packet 

containing a GACH. 

   the label stack. 

   user-plane packets.  

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

From: [email-masked]  <mailto:[email-masked]>
<mailto:[email-masked]> [mailto:[email-masked]] On 

came 

thought). 

GAL 

Section 

the 

Ben 

On 07/01/2009 10:06, "Loa Andersson"  <mailto:[email-masked]> <[email-masked]>
<mailto:[email-masked]> <mailto:[email-masked]> wrote: 

    All, 

mailing list. 

    /Loa 

mpls-tp mailing list 

mpls-tp mailing list 

  

-- 

-- 

  _____

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 17 Jan 2009 10:21:02 +0100

Ben,

Also the approach taken in G.8110.1. Refer to appendix IV/G.8110.1 
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.8110.1-200707-I!Amd
1!PDF-E&type=items.

As I wrote in my previous email, this Section layer LSP signal is
"unlabelled" on the interface.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: vrijdag 16 januari 2009 19:20
To: Martin Vigoureux; BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last Call
ondraft-ietf-mpls-tp-gach-gal-01

Ben

On 16/01/2009 17:28, "Martin Vigoureux"
<[email-masked]> wrote:

> Deborah,
> 
> I guess Dieter's e-mail was referring to the fact that, in the 
> proposed reshaped first paragraph, the applicability of GAL to MPLS 
> Sections disappeared.
> 
>> My suggestions were based on the current text  can you suggest how 
>> to reword?  I¹m not the editor;-).
>> 
>> Deborah
>> 
>>  
>> 
>> that the GAL/GACH can be used as management communication channel and 
>> as signaling communication channel that is NOT associated with an 
>> LSP, i.e., the GAL is the top of stack and bottom of stack at the 
>> same timein this case.
>> A new I-D is in preparation that provides the details and we intend 
>> to submit it in the coming days.
>> 
>> 
>> Cheers,
>> Dieter
>>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 17 Jan 2009 18:34:46 +0100

Hi,
If so, should we define TCME in order to monitor a section and have two labels in the OAM message, one for the TCME and one of the gal?
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Ben Niven-Jenkins
Sent: Friday, January 16, 2009 20:20
To: Martin Vigoureux; BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last Call ondraft-ietf-mpls-tp-gach-gal-01

Ben

---

From: "Eric Gray" <[email-masked]>
Date: Sat, 17 Jan 2009 12:20:33 -0600

Available at:

http://www.ietf.org/internet-drafts/draft-gray-mpls-tp-nm-req-02.txt
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Vishwas Manral" <[email-masked]>
Date: Sat, 17 Jan 2009 20:10:19 -0800

Hi Eric,

Thanks for sending the draft across. I looked at the Security aspects
of what you have written and found a few discrepancies. I also looked
at the other sections as an after thought.

1. In Section 8.1.1
        - Use of open cryptographic algorithms (See RFC 3871 [5]
           section 4.5)

There is no Section 4,.5 in the RFC.

2.         - Allow management connectivity only from authorized IP
           addresses or MAC Addresses

I think a better way to state it would be data origin authentication -
which I guess is the same as point 2. Also the use of authentication
algorithms as reccomended by the IETF.

3. Isn't data confidentiality a concern in the case of MPLS-TP where
we have an offline/ no control plane? In the security section we do
talk about unauthorized eves dropping and solutions for that MUST be
provided.

4. For the DDOS you state that:

It is possible to lessen the impact and potential for DDOS by using
secure protocols

This is not necessarily true. If we have to do more processing for a
packet the use of CPU is more so the chances of a DOS attack is more.
Protocols provide ways to reduce DOS attack when the cryptographic
algorithms are in use by mechanisms like sequence numbers etc.

5. In the DDOS section you also talk about

turning off unnecessary processes, logging and monitoring, and ingress
filtering.

I think the right terms would be tuning the processes to work
appropriately in case of DDOS is a solution not turning them off.

6. Though we talk about loss ratio measurement and SES, when talking
about collection granularity you talk about absolute packet loss
measurement and not the raiot or also the total number of packets.

7. The term UAS is used first in the document  and the expansion is
defined later.

Thanks,
Vishwas

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 19 Jan 2009 08:12:50 +0100

Did not get any response, so I re-send........

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Saturday, January 17, 2009 19:35
To: 'ext Ben Niven-Jenkins'; Martin Vigoureux; BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: [mpls-tp] [mpls] Working Group Last Call ondraft-ietf-mpls-tp-gach-gal-01

Hi,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Ben Niven-Jenkins
Sent: Friday, January 16, 2009 20:20
To: Martin Vigoureux; BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last Call ondraft-ietf-mpls-tp-gach-gal-01

Ben

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 09:06:10 -0000

Nurit,

I am not sure what you are asking here....so let me see if I can understand your question.  

Let's look at the labelling requirements of a normal N hop LSP in a single MPLS-TP layer network when using the GAL for both CP/MP indicate and OAM indicate.

On an arbitrary single hop the traffic units will have some single label X (S=1) say.  On this same hop an OAM pkt would have 2 labels of GAL (S=1) + X (S=0).  However, on this same single hop the CP/MP pkts will have the labelling GAL (S=1) here.

If we now specify a lower level 'section' (sic) level OAM function of a single hop this too looks like it should only have a single label GAL (S=1).  So it is not immediately obvious from the labelling at least what is CP/MP and what is single hop OAM.

Of course if the CP/MP label could not appear in the DP (ie we use a different reserved value for the CP/MP to that used for OAM indicate) then we would be able to distinguish one hop OAM from CP/MP pkts.

So is this the issue you are asking about here? 

Aside 1 => The correct way for OAM indicate would not be to use a reserved label at all but to have this function as part of the normal traffic unit header....the reason being that we want the OAM pkts to look as identical to traffic pkts as possible, and so having 2 labels (for OAM) instead of 1 (for traffic) is not a good idea.  However, although the TTL field has no value as originally intended in a co mode layer network (since the CP/MP can verify no looping prior to establishing a connection, as indeed in the case now for GMPLS when applied to co-cs mode technologies like SDH or OTN) if we cannot reuse this field for whatever reason then I think we should use a different reserved label for the OAM indicate function as opposed to the CP/MP.

Aside 2 => I would be very cautious in venturing down the TCM route for many reasons.  But before any decision on TCM is taken I would advise that folks are very clear on 2 things:
-	the implementation implications of dynamic configuration of nested TCM config across failures/restores, eg how nested TCM level are activated/deactivated in old/new locations and the implications for any PM (eg loss) measurements in nested TCM levels that straddle such events;
-	the commercial/security/regulatory impact of having MEPs/MIPs belonging to different parties embedded in nodes of some other party.

I will ignore the complications that any notion of peer interworking of MPLS-TP with any other layer network technology will incur wrt TCM since I am assuming we will be sensible enough not to go here.

Aside 3 => We should also think about how we are going to do C/S MPLS-TPoverMPLS-TP.  I strongly believe we should a DP indicate function for this in order to verify what the CP/MP thinks is happening.  And I would use yet another different reserved label for this purpose.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 19 January 2009 07:13
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
> Niven-jenkins,B,Ben,DMF R; Martin Vigoureux; BRUNGARD, 
> DEBORAH A, ATTLABS
> Cc: [email-masked]
> If so, should we define TCME in order to monitor a section 
> and have two labels in the OAM message, one for the TCME and 
> one of the gal?
> Best regards,
> Nurit
> 
> [mailto:[email-masked]] On Behalf Of ext Ben Niven-Jenkins
> Applicability of GAL to MPLS Sections disappears because MPLS 
> Section is just a special case of an LSP segment (my original 
> proposal). So MPLS sections are covered in the first 
> paragraph when it says "LSP Segments" (as are Tandem 
> Connections which are also just LSP segments).
> 
> Ben
> 
> 
> applicability 
> >> of

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 19 Jan 2009 10:18:48 +0100

Ben,

there was a lot of discussions on that subject few months back
and I do not recall we reached such conclusion, but my memory
may be playing tricks to me.
My understanding of MPLS Sections is that they may indeed be
a LSP provided by an underlying network but they may also be
a SDH connection, a switched wavelength or even a p2p phy. link
and thus MPLS Sections are not just a special case of LSP segment
or at least not just a special case of MPLS LSP segment.
But that is solely my understanding. :-)

regards,
-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 19 Jan 2009 10:23:40 +0100

So in your view, when we want to monitor a section, should we just use GAL in the OAM messages, with no other label stacked above or should we define a TCME (with 1:N mapping for all LSPs transmitting above the section) and have a label for the TC?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Martin Vigoureux
Sent: Monday, January 19, 2009 11:19
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last Callondraft-ietf-mpls-tp-gach-gal-01

Ben,

regards,
-m

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 19 Jan 2009 10:29:06 +0100

Nurit,

I believe that we should just use the GAL in the OAM messages,
with no other label and this is what has been described in the GAL
and then GAL/GACH drafts since the beginning.
In my view, monitoring MPLS Sections is equivalent to monitoring
as a whole all the LSPs that run over it (implicit 1:N mapping).

regards,
-m

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 09:38:16 -0000

Martin...a couple of comments in-line: 

Martin Vigoureux wrote 19 January 2009 09:19
 
> Ben,
> 
> there was a lot of discussions on that subject few months 
> back and I do not recall we reached such conclusion, but my 
> memory may be playing tricks to me.
> a LSP provided by an underlying network

NH=> Indeed so....but this requires we crack the MPLS-TPoverMPLS-TP
client/server issue....which I why included this point in my last mail,
ie it is not sufficient only to look at OAM indicate and CP/MP indicate
functionality, we also need to solve the C/S issue at the same time to
make sure it all hangs together.

> but they may also be 
> a SDH connection, a switched wavelength or even a p2p phy.

NH=> Yes of course.  Ultimately we have to modulate an EM wave at the
very bottom of the stack or else no information gets transferred....and
I would reserve the term 'section layer' specifically for technologies
that can 'put the bits of the wire' like this, MPLS/MPLS-TP cannot do
this.

regards, Neil
<snipped to end>

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 09:41:32 -0000

Martin...so just to be really clear here....are you saying that it's OK how have 1-hop segment OAM and OOB CP/MP pkts both having a single label of GAL (S=1) between nodes?  I personally think that CP/MP PDUs should not use labels that can appear in the traffic DP....but that is just IMO.

regards, Neil 

> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: 19 January 2009 09:29
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: [email-masked]
> Subject: Re: [mpls-tp] [mpls] Working Group 
> LastCallondraft-ietf-mpls-tp-gach-gal-01
> 
> Nurit,
> 
> I believe that we should just use the GAL in the OAM 
> messages, with no other label and this is what has been 
> described in the GAL and then GAL/GACH drafts since the beginning.
> In my view, monitoring MPLS Sections is equivalent to 
> monitoring as a whole all the LSPs that run over it (implicit 
> 1:N mapping).
> 
> regards,
> -m
> 
> > So in your view, when we want to monitor a section, should 
> we just use GAL in the OAM messages, with no other label 
> stacked above or should we define a TCME (with 1:N mapping 
> for all LSPs transmitting above the section) and have a label 
> for the TC?
> > 
> > Behalf Of ext Martin Vigoureux
> back and I 
> > do not recall we reached such conclusion, but my memory may 
> be playing 
> > tricks to me.
> > My understanding of MPLS Sections is that they may indeed be a LSP 
> > provided by an underlying network but they may also be a SDH 
> > connection, a switched wavelength or even a p2p phy. link and thus 
> > MPLS Sections are not just a special case of LSP segment or 
> at least 
> > not just a special case of MPLS LSP segment.
> >> Applicability of GAL to MPLS Sections disappears because 
> MPLS Section 
> >> is just a special case of an LSP segment (my original 
> proposal). So 
> >> MPLS sections are covered in the first paragraph when it says "LSP 
> >> Segments" (as are Tandem Connections which are also just 
> LSP segments).
> >>
> >> Ben
> >>
> >>
> >>>> I have no problem with your change proposal. But, please keep in 
> >>>> mind that the GAL/GACH can be used as management communication 
> >>>> channel and as signaling communication channel that is NOT 
> >>>> associated with an LSP, i.e., the GAL is the top of stack and 
> >>>> bottom of stack at the same timein this case.
> >>>>    user-plane packets.  Furthermore, the GAL MUST only 
> appear once 
> >>>> in
> >>>>
> >>>> My other LC comment on draft-ietf-mpls-tp-gach-gal-01 
> follows (when 
> >>>> I
> >>>>
> >>>> came
> >>>>
> >>>> to review the draft it appears I don't have as many 
> comments as I 
> >>>> first
> >>>>
> >>>> thought).
> >>>>
> >>>>  
> >>>>
> >>>> Section 3.2.  Is it worth explicitly stating in this 
> section that 
> >>>> the
> >>>>
> >>>> GAL
> >>>>

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 19 Jan 2009 10:59:57 +0100

Neil,

yes.
the GAL does not appear in the stack when transporting
user-plane packet.

regards,
-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 19 Jan 2009 11:01:46 +0100

Hi Martin,
Thanks for your view. 
You are right that this was described in the GAL document, but it was my understanding (but I may get it wrong) that in the discussion in the mailing list on the last call it was required to remove this section. Later on, I learnt about the intention of defining this as a special case of an LSP segment. I can really see the architectural benefit in the idea of having this as a sub/special case of Segment (thus implementing two labels, one of the TCME and one of the GAL). We could also think about your proposal as a sub case (having only GAL) if you think of using the TCME's label combined with PHP - then you get only the GAL :-)
I am a little bit concerned, as we happen to have a lot of discussions in the mailing list with no convergence to real conclusions. 
Best regards,
Nurit

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Monday, January 19, 2009 11:29
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Ben Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last Callondraft-ietf-mpls-tp-gach-gal-01

Nurit,

regards,
-m

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 10:09:05 -0000

Martin,

Martin Vigoureux wrtote 19 January 2009 10:00
> the GAL does not appear in the stack when transporting 
NH=> I am not sure you got my point.  Yes I know when sending traffic we do *not* add the GAL.  But my point was that on a single hop between logically adjacent nodes in the same MPLS-TP layer network (I choose these words carefully as I also have an eye on the C/S case of MPLS-TPoverMPLS-TP) then both CP/MP pkts and 1-hop segment OAM only have the GAL....or at least that is what I am assuming from Nurit's original question.

BTW - When I say 'DP' this includes OAM pkts and not just true traffic pkts....as both appear in the DP.

regards, Neil
> > Martin...so just to be really clear here....are you saying 
> that it's OK how have 1-hop segment OAM and OOB CP/MP pkts 
> both having a single label of GAL (S=1) between nodes?  I 
> personally think that CP/MP PDUs should not use labels that 
> can appear in the traffic DP....but that is just IMO.
> > 
> > regards, Neil
> > 
> messages, with 
> >> no other label and this is what has been described in the GAL and 
> >> then GAL/GACH drafts since the beginning.
> monitoring as a 
> >> whole all the LSPs that run over it (implicit 1:N mapping).
> >>
> >> regards,
> >> -m
> >>
> >> we just use GAL in the OAM messages, with no other label stacked 
> >> above or should we define a TCME (with 1:N mapping for all LSPs 
> >> transmitting above the section) and have a label for the TC?
> >>>>>> The 'Generic Associated channel header Label (GAL)' 
> MUST only be 
> >>>>>> used
> >>>>>>
> >>>>>>    In MPLS-TP, the GAL MUST always be at the bottom of 
> the label 
> >>>>>> stack
> >>>>>>
> >>>>>>    (i.e.  S bit set to 1).  However, in other MPLS 
> environments, 
> >>>>>> this
> >>>>>>
> >>>>>>    The GAL MUST NOT appear in the label stack when 
> transporting 
> >>>>>> normal
> >>>>>>
> >>>>>>    In MPLS-TP, the GAL MUST always be at the bottom of 
> the label 
> >>>>>> stack
> >>>>>>
> >>>>>>    (i.e.  S bit set to 1).  However, in other MPLS 
> environments, 
> >>>>>> this
> >>>>>>
> >>>>>>    The GAL MUST NOT appear in the label stack when 
> transporting 
> >>>>>> normal
> >>>>>>
> >>>>>>    user-plane packets.
> >>>>>>
> >>>>>>  
> >>>>>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 19 Jan 2009 12:28:57 +0000

Martin,

This is maybe something to whiteboard this week when you are in Ipswich.

This is my thinking.

An LSP is constructed of 1 or more concatenated (lower server layer) link
connections.  The lower server layer could be any technology (including
MPLS-TP). What you want to do with a tandem connection is monitor part of
that path at the MPLS-TP layer. What you want to do with an MPLS Section is
monitor at the MPLS-TP layer a single (lower server layer) link connection.

In other words what both tandem connections and MPLS Section OAM achieve is
to monitor part of an MPLS path. Part of an LSP path is defined as an LSP
segment.

The reason the MPLS Section is a "special" case is that as proposed the GAL
is both bottom & top of stack (as there is no forwarding label).

HTH
Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 13:59:04 +0100

Ben,

When rereading your words I suddenly noticed that those include an incorrect
element. The MPLS section is **not** a "LSP Segment", it is a "LSP" in a
Section layer network. A tandem connection is a "LSP Segment".

A MPLS-TP network with MPLS-TP Channel, MPLS-TP Path and MPLS-TP Section
layer networks has an LSP in each of these layer networks, and each of these
LSPs has one or more LSP Segments.

The MPLS-TP Section LSP is special as it is unlabelled when transported over
the physical media directly. When this MPLS-TP Section LSP is transported
through a third party network, then in this third party network the Section
LSP is labelled.

The MPLS-TP Channel LSP is special as well as it carries a non-MPLS client
signal; it is referred to as PW and as LSP Segment.

In terms of G.805, we need to define compatible terms for the set of
transport entities in each of these layer networks. May I ask you to help
fill in/correct the following list:

    ITU-T term                            IETF term
----------------------------------------------------
MPLS-TP Channel Trail				MPLS-TP MS-PW
MPLS-TP Channel Network Connection		MPLS-TP MS-PW
MPLS-TP Channel SubNetwork Connection	MPLS-TP MS-PW LSP segment
MPLS-TP Channel Tandem Connection		MPLS-TP MS-PW LSP segment
MPLS-TP Channel Link Connection		MPLS-TP MS-PW LSP segment

MPLS-TP Path Trail				MPLS-TP Tunnel LSP
MPLS-TP Path Network Connection		MPLS-TP Tunnel LSP
MPLS-TP Path SubNetwork Connection		MPLS-TP Tunnel LSP segment
MPLS-TP Path Tandem Connection		MPLS-TP Tunnel LSP segment
MPLS-TP Path Link Connection			MPLS-TP Tunnel LSP segment

MPLS-TP Section Trail				MPLS-TP Section LSP
MPLS-TP Section Network Connection		MPLS-TP Section LSP
MPLS-TP Section SubNetwork Connection	MPLS-TP Section LSP segment
MPLS-TP Section Tandem Connection		MPLS-TP Section LSP segment
MPLS-TP Section Link Connection		MPLS-TP Section LSP segment

ETH Channel connectionless Trail		VPLS
ETH Channel Network FDFr			VPLS
ETH Channel SubNetwork FDFr			VPLS segment
ETH Channel Tandem FdFr				VPLS segment
ETH Channel Link Connection			VPLS segment/SS-PW

Regards,
Maarten

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

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 14:11:23 +0100

Martin,

A MPLS-TP Section connection is an LSP in the MPLS-TP Section layer network.
In G.8110.1 we have stated in in appendix IV the following about this
section layer:

"An optional TMS layer network instance provides the section-layer
functionality; a TMS connection carries one or more TMP signals between
T-MPLS network nodes. The TMS layer network instance provides OAM for
connection monitoring of the point-to-point transmission media layer signal
that interconnects T-MPLS network nodes. This optional TMS layer network
instance would typically be used in cases where the physical media layer
doesn’t support the required OAM functionality adequately, the TMS
connection spans more than one physical link or the TMS connection is
protected." 

The MPLS-TP Section layer is optional and may not be present when the
physical media layer supports MPLS-TP section layer equivalent functions. 
- Examples of such physical media layers are SDH and OTN. In SDH the VC-n,
and in OTN the ODUk provide MPLS-TP section layer equivalent functions. 
- 802.3 physical media layer does not support such section layer equivalent
functions and it is necessary to deploy a MPLS-TP Section layer between the
ETY and MPLS-TP Path layers. 
- If the 802.3 physical media layer comes with an ETH layer, then this ETH
layer will perform the section layer functionality. In this case it is not
necessary to deploy an MPLS-TP Section layer.

It is possible/allowed to deploy a MPLS-TP Section layer on top of every
type of physical media layer to give MPLS-TP network management a simple and
physical media layer independent layer stack.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Martin Vigoureux
Sent: maandag 19 januari 2009 10:19
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last
Callondraft-ietf-mpls-tp-gach-gal-01

Ben,

there was a lot of discussions on that subject few months back and I do not
recall we reached such conclusion, but my memory may be playing tricks to
me.
My understanding of MPLS Sections is that they may indeed be a LSP provided
by an underlying network but they may also be a SDH connection, a switched
wavelength or even a p2p phy. link and thus MPLS Sections are not just a
special case of LSP segment or at least not just a special case of MPLS LSP
segment.
But that is solely my understanding. :-)

regards,
-m

Ben Niven-Jenkins a écrit :
> Applicability of GAL to MPLS Sections disappears because MPLS Section 
> is just a special case of an LSP segment (my original proposal). So 
> Segments" (as are Tandem Connections which are also just LSP segments).
> 
> Ben
> 
> 
>>> associated with an LSP, i.e., the GAL is the top of stack and bottom 
>>> of stack at the same timein this case.

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 19 Jan 2009 14:16:32 +0100

Ben,

I agree with the proposal to discuss this at the whiteboard.

I would just point out that the original intention of the MPLS Section definition was different from monitoring an LSP link connection.

LSP Link connection OAM monitors a specific LSP between two adjacent LSRs. This OAM is bound to the LSP and exists if and only if the LSP exists.
This is 100% equivalent to a single-hop TCM and we did not see any reason to define a special name.

Section OAM monitors all the LSPs, as a whole, between two MPLS-TP nodes that are connected by a server layer trail. This OAM is not bound to any LSP and can exist also if no LSP is setup between these two nodes.

The original intention for defining MPLS-TP Section OAM was to provide OAM capabilities when the server layer OAM are not adequate.

Italo

> Sent: Monday, January 19, 2009 1:29 PM
> To: VIGOUREUX MARTIN
> Cc: [email-masked]
> MPLS Section is
> the label stack
> environments, this
> transporting normal
> appear once in
> the label stack
> environments, this
> transporting normal
> follows (when I
> comments as I first
> section that the

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 14:28:30 +0100

Nurit,

I am creating a document in which I describe MPLS-TP equipment types and
characteristics. I have uploaded a draft 0.0 of this document to
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-typ
es-and-characteristics-00.doc. In this draft you find in secton 8 the basic
frame formats (no TCM yet) presented of the MPLS-TP channel, path, section
layer AI and CI and of the ETH channel CI.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: maandag 19 januari 2009 10:24
To: ext Martin Vigoureux; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group
LastCallondraft-ietf-mpls-tp-gach-gal-01

So in your view, when we want to monitor a section, should we just use GAL
in the OAM messages, with no other label stacked above or should we define a
TCME (with 1:N mapping for all LSPs transmitting above the section) and have
a label for the TC?

-----Original Message-----
Of ext Martin Vigoureux

Ben,

regards,
-m

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 14:38:51 +0100

Nurit,

As I described in some earlier emails, a MPLS-TP Section is one of the three
MPLS-TP layer netowrks in the layer stack of an MPLS-TP network. The MPLS-TP
Section Characteristic Information (CI) can be carried over the physical
media layer as an "unlabelled MPLS-TP Section LSP", or as a "labelled
MPLS-TP Section LSP". 

The presence of the MPLS-TP Path/Tunnel labels in the non-OAM packets and
the presence of the GAL in the OAM packets allows to pass the MPLS-TP
Section CI as an unlabelled-Section-LSP and reuse the TC bits of the
Path/Tunnel label and in the GAL to carry the QoS information of the
Section-LSP.

In the channel and path layers it is not necessary that the GAL carries the
QoS information of the MPLS-TP OAM as this information is carried in the TC
bits of the LSP or LSP-segment label.

Regards,
Maarten

-----Original Message-----
Sent: maandag 19 januari 2009 11:02
To: ext Martin Vigoureux

Hi Martin,
Thanks for your view. 
You are right that this was described in the GAL document, but it was my
understanding (but I may get it wrong) that in the discussion in the mailing
list on the last call it was required to remove this section. Later on, I
learnt about the intention of defining this as a special case of an LSP
segment. I can really see the architectural benefit in the idea of having
this as a sub/special case of Segment (thus implementing two labels, one of
the TCME and one of the GAL). We could also think about your proposal as a
sub case (having only GAL) if you think of using the TCME's label combined
with PHP - then you get only the GAL :-) I am a little bit concerned, as we
happen to have a lot of discussions in the mailing list with no convergence
to real conclusions. 
Best regards,
Nurit

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]]
Sent: Monday, January 19, 2009 11:29
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Ben Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last

Nurit,

I believe that we should just use the GAL in the OAM messages, with no other
label and this is what has been described in the GAL and then GAL/GACH
drafts since the beginning.
In my view, monitoring MPLS Sections is equivalent to monitoring as a whole
all the LSPs that run over it (implicit 1:N mapping).

regards,
-m

> there was a lot of discussions on that subject few months back and I 
> do not recall we reached such conclusion, but my memory may be playing 
> tricks to me.
> MPLS Sections are not just a special case of LSP segment or at least

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 14:41:27 +0100

Neil,

If you want to see packet formats in a MPLS-TP layer netowrk, then you can
have a look at figures 31 to 34 in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-typ
es-and-characteristics-00.doc.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 19 januari 2009 11:09
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working
GroupLastCallondraft-ietf-mpls-tp-gach-gal-01

Martin,

> 
> Neil,
> 
> yes.
> the GAL does not appear in the stack when transporting user-plane 
> packet.
NH=> I am not sure you got my point.  Yes I know when sending traffic we do
*not* add the GAL.  But my point was that on a single hop between logically
adjacent nodes in the same MPLS-TP layer network (I choose these words
carefully as I also have an eye on the C/S case of MPLS-TPoverMPLS-TP) then
both CP/MP pkts and 1-hop segment OAM only have the GAL....or at least that
is what I am assuming from Nurit's original question.

BTW - When I say 'DP' this includes OAM pkts and not just true traffic
pkts....as both appear in the DP.

regards, Neil
> that it's OK how have 1-hop segment OAM and OOB CP/MP pkts both having 
> a single label of GAL (S=1) between nodes?  I personally think that 
> CP/MP PDUs should not use labels that can appear in the traffic 
> DP....but that is just IMO.
> > 
> > regards, Neil
> > 
> MUST be used

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 15:52:07 +0100

Neil,

The MCC/SCC carrying MP/CP information is one of the types of Operation
Administration and Maintenance information that is carried behind the GAL.
The channel type field in the GAL header carries the OpCode that identifies
the type of OAM, including the type of MCC/SCC.

The GAL is not a real label, it is a Protocol Type header. For OAM it is a
protocol type header (type = OAM, incl MCC/SCC) and an OpCode field. As such
the OAM packets have the same number of labels as the non-OAM packets,
namely 1 label or 0 labels. The latter in case the MPLS-TP Section LSP is
transported over its link in an unlabelled format.

The most simple encoding for such channel type in case of OAM is to reserve
256 channel type values for OAM, incl. MCC/SCC and use the Y.1731 OpCode
values as value for the 8 least significant bits of the channel type and use
a fixed value (e.g. 0x02) for the 8 most significant bits of the channel
type field.

As I wrote to you in an earlier email, the MPLS(-TP) protocol type
information is distributed over multiple fields. The S-bit is part of the
Protocol Type information, also the 4-bit nibble following the bottom LSE
header and now also the Channel Type field.

In MPLS-TP the CW is mandatory, so the 4-bit nibble field is in all packets
present. 

The existing client into PW mapping specifications are lacking a Channel
Type field, in which the type of client_CI being carried is indicated. It is
too late to add this, so we have to live with it.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 19 januari 2009 10:06
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group
LastCallondraft-ietf-mpls-tp-gach-gal-01

Nurit,

I am not sure what you are asking here....so let me see if I can understand
your question.  

Let's look at the labelling requirements of a normal N hop LSP in a single
MPLS-TP layer network when using the GAL for both CP/MP indicate and OAM
indicate.

On an arbitrary single hop the traffic units will have some single label X
(S=1) say.  On this same hop an OAM pkt would have 2 labels of GAL (S=1) + X
(S=0).  However, on this same single hop the CP/MP pkts will have the
labelling GAL (S=1) here.

If we now specify a lower level 'section' (sic) level OAM function of a
single hop this too looks like it should only have a single label GAL (S=1).
So it is not immediately obvious from the labelling at least what is CP/MP
and what is single hop OAM.

Of course if the CP/MP label could not appear in the DP (ie we use a
different reserved value for the CP/MP to that used for OAM indicate) then
we would be able to distinguish one hop OAM from CP/MP pkts.

Aside 1 => The correct way for OAM indicate would not be to use a reserved
label at all but to have this function as part of the normal traffic unit
header....the reason being that we want the OAM pkts to look as identical to
traffic pkts as possible, and so having 2 labels (for OAM) instead of 1 (for
traffic) is not a good idea.  However, although the TTL field has no value
as originally intended in a co mode layer network (since the CP/MP can
verify no looping prior to establishing a connection, as indeed in the case
now for GMPLS when applied to co-cs mode technologies like SDH or OTN) if we
cannot reuse this field for whatever reason then I think we should use a
different reserved label for the OAM indicate function as opposed to the
CP/MP.

Aside 2 => I would be very cautious in venturing down the TCM route for many
reasons.  But before any decision on TCM is taken I would advise that folks
are very clear on 2 things:
-	the implementation implications of dynamic configuration of nested
TCM config across failures/restores, eg how nested TCM level are
activated/deactivated in old/new locations and the implications for any PM
(eg loss) measurements in nested TCM levels that straddle such events;
-	the commercial/security/regulatory impact of having MEPs/MIPs
belonging to different parties embedded in nodes of some other party.

I will ignore the complications that any notion of peer interworking of
MPLS-TP with any other layer network technology will incur wrt TCM since I
am assuming we will be sensible enough not to go here.

Aside 3 => We should also think about how we are going to do C/S
MPLS-TPoverMPLS-TP.  I strongly believe we should a DP indicate function for
this in order to verify what the CP/MP thinks is happening.  And I would use
yet another different reserved label for this purpose.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - 
> IL/Hod HaSharon)
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Niven-jenkins,B,Ben,DMF 
> R; Martin Vigoureux; BRUNGARD, DEBORAH A, ATTLABS
> Cc: [email-masked]
> If so, should we define TCME in order to monitor a section and have 
> two labels in the OAM message, one for the TCME and one of the gal?
> Best regards,
> Nurit
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 19 Jan 2009 15:04:31 +0000

Maarten,

My understanding of the current proposed solution is not the same as yours,
i.e. I understand that a single MPLS label stack (i.e. Sub layering) will be
used not a number of independent layer networks as you seem to propose.

However,

> Section layer network. A tandem connection is a "LSP Segment".

MPLS equipment is connected together using link connections in a lower layer
network.  Those link connections are "sections" at the MPLS layer.  The MPLS
layer may take them as they are or may "add on top" its own section
functionality (e.g. OAM).

If it adds on top then for OAM it has a GAL running directly over the link
connection (i.e. There is no MPLS forwarding label). Case (1)

If I create an End to End LSP that traverses a concatenated number of these
sections then that LSP also runs directly over each section but its top most
label is a forwarding label and not a GAL.  Case (2).

Therefore the GAL/OAM in Case (1) is monitoring an LSP segment of the LSP in
Case (2).

Put in as many sublayers as you like and the OAM in Case (1) is still
monitoring a segment of one or more LSPs.

It is all in the same layer network because they are all sub-layers of a
single layer network.

Ben

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 15:57:27 -0000

Thanks Maarten,

Are you saying it is agreed that there are 3 distinct layer networks in MPLS-TP (each having a quite distinct CP/MP/DP)?...and which, if true, means the client/server problem has been solved (in some sense)?....so what would MPLS-TPoverMPLS-TP now look like (and which of the 3 layer networks you describe would we be talking about here)?

And do I also take it that this is quite unlike MPLS as-is that currently uses sublayers (ie the S bit).  Indeed, is there still any notion of using the S bit for sublayering in what you are decribing here Maarten?

This is all news to me (and also Ben it seems seeing his mail saying similar).  

regards, Neil

> Sent: 19 January 2009 13:39
> To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'
> Cc: [email-masked]
> As I described in some earlier emails, a MPLS-TP Section is 
> one of the three MPLS-TP layer netowrks in the layer stack of 
> an MPLS-TP network. The MPLS-TP Section Characteristic 
> Information (CI) can be carried over the physical media layer 
> as an "unlabelled MPLS-TP Section LSP", or as a "labelled 
> MPLS-TP Section LSP". 
> 
> The presence of the MPLS-TP Path/Tunnel labels in the non-OAM 
> packets and the presence of the GAL in the OAM packets allows 
> to pass the MPLS-TP Section CI as an unlabelled-Section-LSP 
> and reuse the TC bits of the Path/Tunnel label and in the GAL 
> to carry the QoS information of the Section-LSP.
> 
> In the channel and path layers it is not necessary that the 
> GAL carries the QoS information of the MPLS-TP OAM as this 
> information is carried in the TC bits of the LSP or LSP-segment label.
> 
> Regards,
> Maarten
> 
> You are right that this was described in the GAL document, 
> but it was my understanding (but I may get it wrong) that in 
> the discussion in the mailing list on the last call it was 
> required to remove this section. Later on, I learnt about the 
> intention of defining this as a special case of an LSP 
> segment. I can really see the architectural benefit in the 
> idea of having this as a sub/special case of Segment (thus 
> implementing two labels, one of the TCME and one of the GAL). 
> We could also think about your proposal as a sub case (having 
> only GAL) if you think of using the TCME's label combined 
> with PHP - then you get only the GAL :-) I am a little bit 
> concerned, as we happen to have a lot of discussions in the 
> mailing list with no convergence to real conclusions. 
> Best regards,
> Nurit
> 
> From: ext Martin Vigoureux 
> [mailto:[email-masked]]
> we just use 
> in the OAM messages, with no other label stacked above or 
> should we define a TCME (with 1:N mapping for all LSPs 
> <mailto:[email-masked]>

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 19 Jan 2009 09:14:45 -0800

Hi Maarten,

> transported over its link in an unlabelled format.
This is true of GAL, if it is never used as a label for any purpose
i.e. ECMP case etc. In which case I do not see why this difference in
the OAM and the Traffic packets is "not a good idea".

Thanks,
Vishwas

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jan 2009 18:21:00 +0100

Ben,

We might run into the terminology issue what a layer network's scope is and
what the scope is of a sublayer. In the G.800 discussion we have identified
two types of layer networks:
1) encapsulation layer network
2) administrative layer network.

I am working from the viewpoint of administrative layer networks. This is
the scope of the daily network management/operation. The encapsulation is an
unmanaged element, as it is something that is fully specified in standards
and does not need any further control. Administrative layer networks have a
n:1 relationship with their client layer networks. This n:1 relationship is
to be managed; an administative layer network trail supports a link in a
client layer, which can carry one or more client signals.

Within the administrative layer network view there is a TCM sublayer, which
monitors in a 1:1 relationship a tandem connection in that layer network.

If you read 
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-typ
es-and-characteristics-00.doc
then you find a brief description of the MPLS-TP (administrative) layer
network stack and the means to operate this (admin) layer network stack in
section 0 of the document. Note in here that the physical media, MPLS-TP
Section and MPLS-TP Path layer connections/trails are set up under control
of network planning and provide the topology of the MPLS-TP/ETH Channel
(admin) layer network, while the MPLS-TP and ETH Channel layer transport
entities are set up under control of a customer's service request. Figure 3
in the document illustrates the channel layer topology that is created under
control of network planning and is then available to create channel layer
transport entities, each supporting one service requests.

See inline for some specific remarks...

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: maandag 19 januari 2009 16:05
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Working Group Last Call

Maarten,

However,

On 19/01/2009 12:59, "Maarten Vissers" <[email-masked]> wrote:
> When rereading your words I suddenly noticed that those include an 
> incorrect element. The MPLS section is **not** a "LSP Segment", it is 
> a "LSP" in a Section layer network. A tandem connection is a "LSP
Segment".

[mv] A Link Connection in the MPLS Section layer is not a Section. It is a
Section layer link connection. A Section layer trail may contain one or more
section layer link connections. A single section link connection is present
when the section trail contains a signle link connection (i.e. passes one
physical media trail). Multiple section link connections are present when
the section trail extends beyond a single physical media trail; e.g. in the
case of passing through a carrier-carrier network.

[mv] If you look at G.8110 you will notice that the MPLS_CI contains a TTL
and S field. This also applies to MPLS_Section_CI. This TTL/S fields are
part of a Section Label Stack Entry header, which is removed from the packet
when it is mapped into the physical media signal. This is explicitly
documented in appendix IV/G.8110.1. As such there is implicitly a forwarding
label, which is only not explicitly present in the packet as its value can
be inferred from the link supported by the physical media trail it is being
carried over. 

[mv] If you look at figures 31 to 34 in my MPLS-TP equipment types document
you find this TTL/S fields presence in the MPLS-TP_CI and removal of those
fields when mapped in the physical media signal. This is the reason I refer
to the MPLS_CI signal as being "unlabelled"; i.e. the label is removed by
the mapping process. 

[mv] If this Section signal would be connected to a carrier-carrier netowrk,
then the section_CI will be extracted from the physical media signal; after
this extraction this section_CI will pass through a Section TCM MEP to allow
the carrier-carrier network to monitor the transport of this signal through
its network. Afterwards this Section_CI signal will be carried trough the
carrier-carrier channel layer netowrk and will be multiplexed with other
channel_CI signals. During this multiplexing this section_CI signal will be
extended with a TC field and a Label field. Now this Section_CI signal is
labelled.

[mv] I am not sure what an End to End LSP is... 
A) it could be a MPLS-TP Section trail that passes through a carrier-carrier
network (as described above), 
B) or it can be a MPLS-TP Path trail that passes through multiple MPLS-TP
Path layer links that are supported by a MPLS-TP Section layer trail,
C) or it can be a MPLS-TP Path trail that passes through multiple MPLS-TP
Path layer links that are supported by a physical media layer trail (i.e.
without the presence of a MPLS-TP Section layer trail).

[mv] If I assume that you refer to case B), then the MPLS-TP Section OAM
(with the GAL at the top of the packet) monitors a MPLS-TP Section layer
trail, which carries a set of MPLS-TP Path layer signal. I.e. it does
**not** monitor an "LSP Segment of the MPLS-TP Path layer trail". If you
want to monitor an LSP segment of one specific MPLS-TP path layer trail you
have to deploy Path layer TCM for that specific trail.

[mv] Now your statement is correct... i.e. monitoring a segment of **one or
more** LSPs. But this is very different from monitoring the segment of
**one** LSP.

[mv] If you look at clause 5.4.1/G.805 you find a number of connection
monitoring techniques described. The MPLS-TP Section trail provides
"inherent monitoring", while MPLS-TP Path TCM provides "sublayer
monitoring".

[mv] As I have indicated, they could be all part of one **encapsulating**
layer network, but they are **not** part of one **administrative** layer
network. And only the latter layer networks are important in the network
management/operation.

[mv] Note that these transport entities in lower administative layer
networks have a longer life time than transport entities in higher
administative layer networks. The longest life times can be found in the
physical media admin layer network, the shortest life times can be found in
the Channel admin layer networks. The Path admin layer netowrk
trails/connections have a longer life time than the channel layer ones, and
the section layer network trails/connections have a longer life time than
the path layer ones.

I hope this clarifies the issue.

Regards,
Maarten

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 19 Jan 2009 09:43:55 -0800

Ben,

This is consistent with my understanding.

Thanks,

John 

>Sent: Monday, January 19, 2009 7:05 AM
>To: Maarten Vissers
>Cc: [email-masked]
>My understanding of the current proposed solution is not the 
>same as yours, i.e. I understand that a single MPLS label 
>stack (i.e. Sub layering) will be used not a number of 
>independent layer networks as you seem to propose.
>
>However,
>
>> a "LSP" in a Section layer network. A tandem connection is a 
>"LSP Segment".
>
>MPLS equipment is connected together using link connections in 
>a lower layer network.  Those link connections are "sections" 
>at the MPLS layer.  The MPLS layer may take them as they are 
>or may "add on top" its own section functionality (e.g. OAM).
>
>If it adds on top then for OAM it has a GAL running directly 
>over the link connection (i.e. There is no MPLS forwarding 
>label). Case (1)
>
>If I create an End to End LSP that traverses a concatenated 
>number of these sections then that LSP also runs directly over 
>each section but its top most label is a forwarding label and 
>not a GAL.  Case (2).
>
>Therefore the GAL/OAM in Case (1) is monitoring an LSP segment 
>of the LSP in Case (2).
>
>Put in as many sublayers as you like and the OAM in Case (1) 
>is still monitoring a segment of one or more LSPs.
>
>It is all in the same layer network because they are all 
>sub-layers of a single layer network.
>
>Ben
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Jan 2009 20:36:58 -0000

I, too, agree with Ben's understanding.

A
----- Original Message ----- 
From: "Drake, John E" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>; "Maarten Vissers" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 19, 2009 5:43 PM
Subject: Re: [mpls-tp] [mpls] Working Group 
LastCallondraft-ietf-mpls-tp-gach-gal-01

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 Jan 2009 12:05:55 +0100

this wg last call has terminated.

What will happen now is that we will receive consolidated comments
from the ITU-T MPLS-TP ad hoc team, we've been promised that we will
those comments "within a few days".

Once we received those comment could the editors/authors please
prepare responses to all comments and re-spin the draft.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Jan 2009 16:54:03 +0100

respect to layer networks and sublayers. You can download those slides from
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-sublayers
-00.ppt.

In the first few slides I have copied the relevant text in G.805 (03/2000)
for layer networks, sublayers and the transport functional group. I have
applied these specifications to several transport network technologies to
illustrate the principles defined. I then have applied these specifications
to the MPLS-TP case.

I have also illustrated the carrier-carrier application in a generic manner
and for several transport network technologies. I have then applied this
carrier-carrier application to the MPLS-TP case.

My conclusion is that G.805 gives clear guidance for the use of the terms
"layer network" and "sublayer". On the basis of G.805, MPLS-TP will contain
multiple "MPLS-TP layer network" instances, and each MPLS-TP layer network
instance may have one or more "connection related SubLayers".

I propose that we add the presented MPLS-TP layer stack with its layer
networks, sublayers and carrier-carrier applications to the MPLS-TP
framework.

Regards,
Maarten

---

From: "Malcolm Betts" <[email-masked]>
Date: Wed, 21 Jan 2009 08:43:59 -0500

[email-masked] list.  I have not seen any suggestions that the ITU-T
needs to provide any formal comments on this draft.  Clearly the
comments should be addressed before the draft is approved.  

Since you have indicated that the draft will be respun, and I assume you
will initiate a new last call, I do not see a need for the ITU to send a
formal liaison in response your request to review this draft.

Malcolm Betts
co chair Ad Hoc group on MPLS-TP
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2009 6:06 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: George Swallow; Matthew Bocci; David Ward; Betts, Malcolm
(CAR:X632); Deborah Brungard; Stewart Bryant; [email-masked]
Subject: Re: [PWE3] Working Group Last Call on
draft-ietf-mpls-tp-gach-gal-01

All,

What will happen now is that we will receive consolidated comments from
the ITU-T MPLS-TP ad hoc team, we've been promised that we will those
comments "within a few days".

Once we received those comment could the editors/authors please prepare
responses to all comments and re-spin the draft.

/Loa

-- 

Loa Andersson

                                       email:
[email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 Jan 2009 19:39:34 +0100

OK.

Editors, Authors,

could you please start working on responses the comments.

/Loa

Malcolm Betts wrote:
> Loa, the comments on the ITU lists have also been submitted on the

-- 

Loa Andersson

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 22 Jan 2009 09:18:54 -0500

during the development G.8110 the MPLS architecture.  We agreed that
MPLS should be modelled using sub layer not new layer networks for each
label push/pop. 

Further people have indicated, on this list, strong support for use of
the sub layer model for MPLS.    

It appears that you are attempting to modify the ITU model via
discussion on an IETF email list.  If you wish to change G.8110 please
send a contribution to the ITU.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Wednesday, January 21, 2009 10:54 AM
To: [email-masked]
Subject: [mpls-tp] Layer networks and sublayers in MPLS-TP

I have created a couple of slides to resolve the ambiguity in MPLS-TP
with respect to layer networks and sublayers. You can download those
slides from
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-subla
yers
-00.ppt.

In the first few slides I have copied the relevant text in G.805
(03/2000) for layer networks, sublayers and the transport functional
group. I have applied these specifications to several transport network
technologies to illustrate the principles defined. I then have applied
these specifications to the MPLS-TP case.

I have also illustrated the carrier-carrier application in a generic
manner and for several transport network technologies. I have then
applied this carrier-carrier application to the MPLS-TP case.

My conclusion is that G.805 gives clear guidance for the use of the
terms "layer network" and "sublayer". On the basis of G.805, MPLS-TP
will contain multiple "MPLS-TP layer network" instances, and each
MPLS-TP layer network instance may have one or more "connection related
SubLayers".

Regards,
Maarten

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 22 Jan 2009 14:33:14 +0000

I agree.  MPLS-TP as specified consist of two layer networks. An "LSP layer
network" (what Maarten's slides refer to as a Path layer network) and a "PW
layer network" (what Maarten's slides refer to as a Channel layer network).

The other deviation is is the Ethernet Channel layer network in Maarten's
slides.  The scope of MPLS-TP is strictly P2P and P2MP LSP and PWs.  MP2MP
and RMP services can be supported over it but it does not itself provides
MP2MP or RMP constructs.  Discussion of MP2MP or RMP Ethernet support over
an MPLS-TP server in IETF comes under the responsibility of the L2VPN WG
IMO.

Ben

On 22/01/2009 14:18, "Malcolm Betts" <[email-masked]> wrote:

> Maarten, as you are aware this issue was discussed in detail in Q12/15

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 22 Jan 2009 15:40:43 +0100

As you can read I am not advocating to introduce a new layer network
isntance for every label push/pop; i.e. the TCM related label push/pop are
not introducting new layer netowrks, only introduce new sublayers. I am only
following G.805 definitions of layer networks and sublayers, in which it is
defined that a new layer network is to be introduced when there is
"independent topology, independent path set up, independent management and
independent design, operation, diagnostics and failure recovery".

I.e. the term "layer network" has a strong association with the
operation/management of a group of atomic functions in the transport
network.

Sublayers don't have this "independent topology" or "independent path set
up". 

Note that the functional models (equipment viewpoint) are not impacted by
the "label" assigned to groups of atomic functions. But from a
management/operational viewpoint it is necessary to use the same terms for
similar functionality over the different transport technologies (SDH, OTN,
ATM, Ethernet, MPLS-TP).

As MPLS-TP is a continuation of T-MPLS, and as G.8110.1 already refers to
those groups of atomic functions as layer networks (i.e. channel, path,
section), I wish to maintain the current specification in G.8110.1; i.e. no
change.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Malcolm Betts
Sent: donderdag 22 januari 2009 15:19
To: [email-masked]
Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Maarten, as you are aware this issue was discussed in detail in Q12/15
during the development G.8110 the MPLS architecture.  We agreed that MPLS
should be modelled using sub layer not new layer networks for each label
push/pop. 

It appears that you are attempting to modify the ITU model via discussion on
an IETF email list.  If you wish to change G.8110 please send a contribution
to the ITU.

Malcolm Betts
Nortel Networks

-----Original Message-----
Of Maarten Vissers

I have created a couple of slides to resolve the ambiguity in MPLS-TP with
respect to layer networks and sublayers. You can download those slides from
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-subla
yers
-00.ppt.

In the first few slides I have copied the relevant text in G.805
(03/2000) for layer networks, sublayers and the transport functional group.
I have applied these specifications to several transport network
technologies to illustrate the principles defined. I then have applied these
specifications to the MPLS-TP case.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 22 Jan 2009 16:20:02 +0100

"LSP Layer Network" and "PW Layer Network" are in my opinion not correct.

If you compare with my "Channel Layer Network", then this Channel Layer
Network contain the PW trail/network connection and zero or more Channel LSP
sublayer trails that provide TCM of the PW network connection.

My Path Layer Network contains the Path LSP trail/network connection and
zero or more Path LSP sublayer trails that provide TCM of the Path LSP
network connection.

My Section Layer Network contains the Section LSP trail/network connection
and zero or more Section LSP sublayer trails that provide TCM of the Section
LSP network connection.

Each of these three Channel/Path/Section Layer Networks has 
- independent topology, 
- independent path set up, 
- independent management and 
- independent design, operation, diagnostics and failure recovery.
And these characteristics makes those according to G.805 "layer networks".

For more then 15 years now, management systems associated "layer networks"
with 
- independent topology, 
- independent path set up, 
- independent management and 
- independent design, operation, diagnostics and failure recovery.

Do we want to change this association in our management systems?
I don't believe that such change will be helpful to introduce MPLS-TP in the
transport networks in any sense. So let's just keep this "layer network"
association.

Sublayers within a specific layer network "identify additional transport
processing functions and reference points". Let's also keep this "sublayer"
association in our management systems.

Note that "label push/pop" will create either
- a sublayer (case of 1:1 relation (TCM)), or
- a layer network (case of n:1 relation (muxing)).

At first instance this may be a bit confusing to people, and deserves as
such specific text in the framework document to explain.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: donderdag 22 januari 2009 15:33
To: Malcolm Betts; [email-masked]
Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Malcolm, Maarten

Ben

On 22/01/2009 14:18, "Malcolm Betts" <[email-masked]> wrote:

> MPLS should be modelled using sub layer not new layer networks for 
> each label push/pop.
> 
> group. I have applied these specifications to several transport 
> network technologies to illustrate the principles defined. I then have 
> applied these specifications to the MPLS-TP case.
> 
> MPLS-TP layer network instance may have one or more "connection 
> related SubLayers".
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 22 Jan 2009 16:23:51 +0000

I am not suggesting we change the definition or association of layer network
or sublayer. I think you misunderstand the terms I used.  MPLS-TP as
currently specified consists of two layer networks:

- A PW layer network, which operates over
- An "LSP"/MPLS-TP layer network.

I used "LSP" to indicate I was talking about the part of MPLS-TP that is the
server layer to the PW layer.

This issue comes from in the past we have PWs and MPLS.  We now have MPLS-TP
which is a combination of PWs and an MPLS profile.  MPLS-TP refers to the
whole thing, what do we use to refer the part of MPLS-TP that sits under the
PWs?  I picked "LSP" layer network.

More inline

> sublayer trails that provide TCM of the PW network connection.

This is synonymous with what I called a PW layer network.

> zero or more Path LSP sublayer trails that provide TCM of the Path LSP

This is synonymous with what I called an LSP layer network.
 
> and zero or more Section LSP sublayer trails that provide TCM of the Section

This confuses me - why would you want different levels of TCM in a section?

I also have other thoughts/questions on section which I will put in a
different mail.
 
> - a layer network (case of n:1 relation (muxing)).

I am not sure that muxing automatically create a new layer network boundary.
If I have LSP hierarchy where I am multiplexing several LSPs into a lower
sublayer LSP for management and operational simplicity and scaling I would
not say that I have two layer networks but two sublayers within a single
MPLS layer network.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 22 Jan 2009 21:37:05 +0100

> The other deviation is is the Ethernet Channel layer network in Maarten's
slides.
> The scope of MPLS-TP is strictly P2P and P2MP LSP and PWs.  MP2MP and RMP
> services can be supported over it but it does not itself provides MP2MP or
RMP constructs. 

The MPLS-TP Path/LSP layer network has as client layer network the ETH
channel layer network. It is important to describe in the MPLS-TP framework
that the ETH channel layer network is a client of the MPLS-TP Path/LSP layer
network. There is no MPLS-TP channel/PW layer network between the ETH
Channel layer network and the MPLS-TP Path/LSP layer network. 

The channel layer terminating and switching MPLS-TP equipment (T-PE and
S-PE) will support both the MPLS-TP channel/PW layer network and ETH channel
layer network. Ethernet UNI-N, I-NNI and E-NNI ports on such T-PE/S-PE nodes
support ETH MEP and ETH MIP functions in parallel to MPLS-TP channel/PW MEP
and MIP functions.

Devices on those interface ports will support both ETH **and** PW MEP/MIP
functions. If a packet with PW label value X may have to be processed by an
ETH MEP/MIP or a PW MEP/MIP function. If PW label value X identifies an
MPLS-TP channel/PW layer connection, then the packets with label value X
will be processed by a PW MEP/MIP function. If the PW label value X
idnetifies an ETH channel layer transport entity (i.e. a VPLS instance),
then the packet will be processed by an ETH MEP/MIP function.

This implies that there is an MPLS-TP Path/LSP to MPLS-TP channel/PW and ETH
channel adaptation function (LSP/PW+ETH_A) function in the MPLS-TP Path/LSP
layer network boundary.

The MPLS-TP framework should recognise this adaptation function.

>From an equipment perspective, it is important to minimize the equipment
complexity. Such is only possible if there is full recognition of the
functionality present in such equipment. For the MPLS-TP equipment this
implies that minimizing equipment complexity can only be obtained when we
understand that PW MEP/MIP functions are paired with ETH MEP/MIP functions.
And thus PW OAM is paired with ETH OAM. For the case a device has to support
e.g. 100  MEP/MIP functions, such device would have to support 100 ETH
MEP/MIP functions and 100 PW MEP/MIP functions. 
- When the PW OAM is very different from the ETH OAM, there would be 100
sets of ETH OAM functions needed in the device plus 100 sets of PW OAM
functions.
- When PW OAM has strong commonality with ETH OAM, then it is possible that
the device supports just 100 sets of common ETH/PW OAM functions (only the
OAM headers differ a bit). A great complexity reduction compared to the
first case.

Then there is the one more item to address. It would be possible to carry
MPLS-TP channel/PW layer signals and ETH channel layer signals directly over
a MPLS-TP Section layer trail, without intermediate MPLS-TP Path/LSP layer
trail. Such would be typically found in access links, between e.g. NTU
devices and Metro Edge devices. Refer to figure 2 in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-typ
es-and-characteristics-00.doc where you find this case illustrated.

It should be made clear in the framework if this carriage of Channel signals
over Section trail is supported in those access links. If supported, then
the MPLS-TP Section layer network will also have the MPLS-TP channel/PW and
ETH channel layers as client layers and will have an MPLS-TP Section to
MPLS-TP channel/PW and ETH channel adaptation function (LSP/PW+ETH_A).

There are two alternatives:
1) require that a MPLS-TP Path/LSP trail is included; i.e. a few MPLS-TP
channel/PW signals and ETH channel signals are then carried in a single
path/lsp trail and this single path/lsp signal is carried in the section/LSP
trail.
2) require that a MPLS-TP Path/LSP trail is used instead of a Section/LSP
trail.

>From an equipment interworking perspective it is important to explicitly
specify the signal format on such access I-NNI.

Regards,
Maarten

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

Malcolm, Maarten

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 22 Jan 2009 22:48:03 +0100

I had a short call with Italo today, in which he made me aware of a
misunderstanding in my mind around PW TCM. I incorrectly had understood that
PW TCM would create an LSP as it is using label stacking. I now understand
that this is not the case... When a PW TCM is created we use label stacking,
but the resulting PW tandem connection is not referred to as a LSP; it is
referred to as a TPME, and the PW TCM OAM does not include a GAL header. I
have corrected the PW TCM OAM packet formats illustrated on slides 22/23 in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/best-mpls-tp-oam-pdu
-formats-02.ppt.

With this issue clarified, I now agree with you that there is 
- a MPLS-TP PW layer netowrk, which I refer to as MPLS-TP channel layer
network, and
- a MPLS-TP LSP layer network, which I refer to as MPLS-TP path layer
network.

In addition there is a second MPLS-TP LSP layer network, which I refer to as
MPLS-TP section layer network.

"MPLS-TP" for me refers to the 
- MPLS-TP channel/PW layer network and its adaptation functions to its
clients
- ETH channel layer network and its adaptation functions to its clients
- MPLS-TP path/LSP layer network and its adaptation functions to its clients
(PW and ETH)
- MPLS-TP section/LSP layer network and its adaptation functions to its
clients (LSP, if supported also PW and ETH, see previous reply to you).
- Physical media layer networks (e.g. ETY, SDH Sn/MSn/RSn, OTN
ODUk/OTUk/OChr/OPS).

I.e. "MPLS-TP" refers to a **complete** solution, not just a partial
solution that is lacking mp2mp and rmp services support.

I would like to ask if it is possible to clarify explicitly in the MPLS-TP
framework is "MPLS-TP" refers to a **complete** packet transport netowrk
solution (as per above), or if it refers to a **partial** packet transport
netowrk solution, excluding the mp2mp and rmp services support. I hope that
the term will refer to the **complete** solution.

----

> not say that I have two layer networks but two sublayers within a single

First let me make a remark that there is a single MPLS technology that can
support multiple G.805 layer networks. As there is for a long time a
discussion ongoing on the scope of a layer network, I expect that in the
near future the term 'layer network' may get associated with more then one
group of atomic functions. To differentiate between the different
associations, it has been suggested to use 'administrative layer network'
and 'encapsulating layer network'. 

The MPLS 'encapsulating layer network' may then include one or more
'administrative layer networks'. 

I am focussed on the 'administrative layer network', which creates
"independent topology, independent path set up, independent management and
independent design, operation, diagnostics and failure recovery". Those are
for me the most important characteristics of a G.805 "layer network". For
others, the layer network "transparency" is the most important
characteristic and the focus is then on the 'encapsulating layer network'.

When you multiplex you create "independent topology, independent path set
up, independent management and independent design, operation, diagnostics
and failure recovery".

When you look at the build up of a transport network, then you first set up
the server trail under control of network planning to establish a link in
the client layer network. Once this client layer link is present, it is
possible for the client layer to start using it and have its path set up
select this link to support one or more of its client layer connections.

I.e. the server layer trail/LSP exists prior to the existence of a client
layer connection/LSP. And a server layer trail/LSP exists post the existence
of a client layer connection/LSP.

For the case of "sublayers", it is not possible to create a sublayer trail
when there is no layer netowrk connection to which this sublayer provides
"additional transport processing functions (e.g. TCM MEPs) and reference
points".

PW TCM and LSP TCM are clear sublayers as those sublayer trails can not
exist without existence of the PW and LSP.

The fact that it has been decided to reuse 'label stacking' for the creation
of sublayer trails is unique in the transport network. TCM in SDH, ATM, OTN
and ETH deploy a very different method, which keeps the connection
configuration in the switching nodes unchanged (which is not the case in PW
TCM/LSP TCM).

Label stacking has now to be associated with (administrative) layer network
creation and with TCM sublayer creation.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: donderdag 22 januari 2009 17:24
To: Maarten Vissers; 'Malcolm Betts'; [email-masked]
Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Maarten,

More inline

On 22/01/2009 15:20, "Maarten Vissers" <[email-masked]> wrote:
> If you compare with my "Channel Layer Network", then this Channel 
> Layer Network contain the PW trail/network connection and zero or more 
> Channel LSP sublayer trails that provide TCM of the PW network connection.

> My Path Layer Network contains the Path LSP trail/network connection 
> and zero or more Path LSP sublayer trails that provide TCM of the Path 
> LSP network connection.

> My Section Layer Network contains the Section LSP trail/network 
> connection and zero or more Section LSP sublayer trails that provide 
> TCM of the Section LSP network connection.

 
> I don't believe that such change will be helpful to introduce MPLS-TP 
> in the transport networks in any sense. So let's just keep this "layer
network"
> association.
> 
> Sublayers within a specific layer network "identify additional 
> transport processing functions and reference points". Let's also keep this
"sublayer"

Ben

> 
> At first instance this may be a bit confusing to people, and deserves 
> as such specific text in the framework document to explain.
> 
> Regards,
> Maarten
> 
> 
> I agree.  MPLS-TP as specified consist of two layer networks. An "LSP 
> layer network" (what Maarten's slides refer to as a Path layer 
> network) and a "PW layer network" (what Maarten's slides refer to as a
Channel layer network).
> 
> The other deviation is is the Ethernet Channel layer network in 
> Maarten's slides.  The scope of MPLS-TP is strictly P2P and P2MP LSP 
> and PWs.  MP2MP and RMP services can be supported over it but it does 
> not itself provides MP2MP or RMP constructs.  Discussion of MP2MP or 
> RMP Ethernet support over an MPLS-TP server in IETF comes under the 
> responsibility of the L2VPN WG IMO.
> 
> Ben
> 
> 
>> Maarten, as you are aware this issue was discussed in detail in 
>> Q12/15 during the development G.8110 the MPLS architecture.  We 
>> agreed that MPLS should be modelled using sub layer not new layer 
>> networks for each label push/pop.
>> 
>> Further people have indicated, on this list, strong support for use 
>> of the sub layer model for MPLS.
>> 
>> discussion on an IETF email list.  If you wish to change G.8110 
>> please send a contribution to the ITU.
>> 
>> Malcolm Betts
>> Nortel Networks
>> http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-su
>> b
>> la
>> yers
>> -00.ppt.
>> 
>> network technologies to illustrate the principles defined. I then 
>> have applied these specifications to the MPLS-TP case.
>> 
>> I propose that we add the presented MPLS-TP layer stack with its 
>> layer networks, sublayers and carrier-carrier applications to the 
>> MPLS-TP framework.
>> 
>> Regards,
>> Maarten
>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 22 Jan 2009 21:52:52 +0000

Before the PWE3 WG was formed a decision was taken in IETF that non MPLS or
IP client layer traffic would always be carried in a PW and not directly
over MPLS. What you are suggesting below is therefore a major deviation from
the current MPLS architecture.

The correct approach I believe would be to write an Internet-Draft proposing
the change to the MPLS architecture and have it debated by the community.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 22 Jan 2009 23:48:56 +0100

The ETH channel layer signals are carried with a CW and PW LSE header, but
these headers do not create a MPLS-TP channel/PW layer network. I.e. there
is no PW OAM in those cases as those PWs are not UNI-to-UNI. The UNI-to-UNI
OAM is the ETH OAM. 

There is as such no deviation from the current MPLS architecture in my
understanding. 
The "PW label stack header" in the "ETH (VPLS)" packet performs the role of
the VLAN Tag as explained in Annex 1 of
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-typ
es-and-characteristics-00.doc. The PW label stack entry header carries the
vlan_identifier, priority and drop_eligible parameters specified in 802.1Q.

Again, this approach minimizes the complexity of MPLS-TP equipment and
minimizes complexity of MPLS-TP network management.

As this seems not to be obvious to you (and most likely others), I propose
to explicitly document this minimized layer stack approach (with ETH channel
layer as a client of MPLS-TP path/LSP layer ntwork) in the MPLS-TP framework
document. And it has to be documented in the I-NNI and E-NNI standards
(G.8112) to make interworking between equipment from different vendors and
operators possible.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: donderdag 22 januari 2009 22:53
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Maarten,

Ben

On 22/01/2009 20:37, "Maarten Vissers" <[email-masked]> wrote:

>> Maarten's
>> The scope of MPLS-TP is strictly P2P and P2MP LSP and PWs.  MP2MP and 
>> RMP services can be supported over it but it does not itself provides 
>> MP2MP or
> RMP constructs. 
> 
> channel layer network. It is important to describe in the MPLS-TP 
> framework that the ETH channel layer network is a client of the 
> MPLS-TP Path/LSP layer network. There is no MPLS-TP channel/PW layer 
> network between the ETH Channel layer network and the MPLS-TP Path/LSP
layer network.
> S-PE) will support both the MPLS-TP channel/PW layer network and ETH 
> channel layer network. Ethernet UNI-N, I-NNI and E-NNI ports on such 
> T-PE/S-PE nodes support ETH MEP and ETH MIP functions in parallel to 
> MPLS-TP channel/PW MEP and MIP functions.
> 
> Devices on those interface ports will support both ETH **and** PW 
> MEP/MIP functions. If a packet with PW label value X may have to be 
> processed by an ETH MEP/MIP or a PW MEP/MIP function. If PW label 
> value X identifies an MPLS-TP channel/PW layer connection, then the 
> packets with label value X will be processed by a PW MEP/MIP function. 
> If the PW label value X idnetifies an ETH channel layer transport 
> entity (i.e. a VPLS instance), then the packet will be processed by an ETH
MEP/MIP function.
> 
> This implies that there is an MPLS-TP Path/LSP to MPLS-TP channel/PW 
> and ETH channel adaptation function (LSP/PW+ETH_A) function in the 
> MPLS-TP Path/LSP layer network boundary.
> 
> From an equipment perspective, it is important to minimize the 
> equipment complexity. Such is only possible if there is full 
> recognition of the functionality present in such equipment. For the 
> MPLS-TP equipment this implies that minimizing equipment complexity 
> can only be obtained when we understand that PW MEP/MIP functions are
paired with ETH MEP/MIP functions.
> And thus PW OAM is paired with ETH OAM. For the case a device has to 
> support e.g. 100  MEP/MIP functions, such device would have to support 
> 100 ETH MEP/MIP functions and 100 PW MEP/MIP functions.
> - When the PW OAM is very different from the ETH OAM, there would be 
> 100 sets of ETH OAM functions needed in the device plus 100 sets of PW 
> OAM functions.
> - When PW OAM has strong commonality with ETH OAM, then it is possible 
> that the device supports just 100 sets of common ETH/PW OAM functions 
> (only the OAM headers differ a bit). A great complexity reduction 
> compared to the first case.
> 
> 
> Then there is the one more item to address. It would be possible to 
> carry MPLS-TP channel/PW layer signals and ETH channel layer signals 
> directly over a MPLS-TP Section layer trail, without intermediate 
> MPLS-TP Path/LSP layer trail. Such would be typically found in access 
> links, between e.g. NTU devices and Metro Edge devices. Refer to 
> figure 2 in 
> http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipme
> nt-typ es-and-characteristics-00.doc where you find this case 
> illustrated.
> 
> It should be made clear in the framework if this carriage of Channel 
> signals over Section trail is supported in those access links. If 
> supported, then the MPLS-TP Section layer network will also have the 
> MPLS-TP channel/PW and ETH channel layers as client layers and will 
> have an MPLS-TP Section to MPLS-TP channel/PW and ETH channel adaptation
function (LSP/PW+ETH_A).
> 1) require that a MPLS-TP Path/LSP trail is included; i.e. a few 
> MPLS-TP channel/PW signals and ETH channel signals are then carried in 
> a single path/lsp trail and this single path/lsp signal is carried in 
> the section/LSP trail.
> 2) require that a MPLS-TP Path/LSP trail is used instead of a 
> Section/LSP trail.
> 
> From an equipment interworking perspective it is important to 
> explicitly specify the signal format on such access I-NNI.
> 
> Regards,
> Maarten
> 
> 
Channel layer network).

---

From: <[email-masked]>
Date: Fri, 23 Jan 2009 09:41:33 -0000

22 January 2009 22:49

> As this seems not to be obvious to you (and most likely 
> others), I propose to explicitly document this minimized 
> layer stack approach (with ETH channel layer as a client of 
> MPLS-TP path/LSP layer ntwork) in the MPLS-TP framework 
> (G.8112) to make interworking between equipment from 
> different vendors and operators possible.

Don't bother.  The 'this seems not to be obvious' problem does not lie
with us (where I think can speak for the majority) but with you I am
afraid Maarten.

So let me repeat what I have said before about this nonsense of creating
E-NNIs and trying to force the industry to take up peer-partition I/W:

Who says we will have E-NNIs here anyway?  How many operators have asked
for this....can they please make their presence known (this is the 4th
time I have asked this question, the previous 3 'asks' had no
responses)?

I know all the 'Implementation Agreement Fora' like MPLSF, MEF, ATMF,
etc have always pushed for NNIs and UNIs when promoting their technology
without, it would seem, understanding the bigger problem...and IMO this
is a very disingenuous and dangerous practice that they should stop.

This situation gets significantly worse if we try and I/W different
technologies as E-NNIs...like Ethernet and MPLS-TP...and much, much
worse if this is then between different operating parties. 

I know some people are thinking of doing this (job creation?  industry
sabotage?) but technically it is a complete waste of time/money (it's
not even a trivial protocol conversion exercise anyway across all DP/CP
components, and operators would never allow this in the MP for security
reasons).

But suppose someone was indeed daft enough to do this, then once one
comes to the end of a concatenated sequence of peer-interworked non
top-of-stack technologies one still has to look upwards to see another
end-end *layer network* above you that is top-of-stack and does have
end-system application adaptation functions, ie truly interfaces with
real *external* message/file/stream applications....noting that this
(communication between agents external to the networks) is the whole
raison d'etre for networking at all (the lower layer peer-interworked
entities have no value at all without this)!

So what one *MUST* conclude here is that we should never have bothered
peer-interworking the server layer network technologies, and instead
just fully terminated them at the I/W point and simply passed the higher
client layer network transparently in the 1st place....because that is
all we end up doing once we get to the end of a sequence of lower layer
concatenated/interworked peers anyway!!!  In plain English...we have
just burned a shed load of money.

This is so blindingly technically obvious/correct that I cannot believe
anyone in their right minds would even think of arguing against it. 

regards, Neil

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Fri, 23 Jan 2009 04:32:25 -0600

Vishwas,

Thanks for your comments. We have discussed your comments among the
editors and also in the MEAD meeting on Thursday and decided on the
following:

#1

Yes, that is a typo. To simply the text, we decided to remove the
mentioning of "section 4.5".

#2 & #3

The second and third dash items of section 8.1.1 have been modified,
along with other modifications, as follow:

-     Authentication - allow management connectivity only from
authenticated entities 

-     Authorization - allow management connectivity originated by an
authorization entity, using (for example) an Access Control List (ACL).

#4 & #5

The purpose of the DDOS section is to ensure that the reader maintains
awareness of the DDOS as an issue and to not provide an exhaustive list
of mechanisms to implement DDOS.  If there is further text or more
examples you would like to see added to the section, please provide
suggested text.

#6

Loss ratio has been added to section 7.2.2. By the way, to better
reflect the intent of this section, its heading has been change from
"Collection Granularity" to "Measurement Scope"; and in the text, the
word "collection" has also been changed to "measurement".

#7

Expansion of UAS has been added prior to its first occurrence.

Regards,

Kam

> From: [email-masked] [mailto:[email-masked]] On
Behalf

> Of Vishwas Manral

> Sent: Saturday, January 17, 2009 11:10 PM

> To: Eric Gray

> Subject: Re: [mpls-tp] There is a new MPLS-TP NM Requierements draft

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 23 Jan 2009 11:02:53 -0800

Now that we have a 2-way handshake in place, here are some more comments:

1. The term OS is not clear below, do we mean OSS (Operational Support
systems in the below):

      For management purpose, every MPLS-TP NE MUST connect to an OS
      either directly or indirectly via another MPLS-TP NE. When an
      MPLS-TP NE is connected indirectly to an OS

2. When talking about MCN requirements we talk about DCN and MCN
interchangeably (loosely used). In my view the DCN is probably a
superset of the MCN.

3. The supervision functions state:

        . Supervision of continuity check functions used to detect a
          broken connection;

        . Supervision of connectivity check functions used to detect
          misconnection;

I do not understand the difference between the above. In my view the
continuity check is for periodic sending of messages "inwards" towards
other MEP's (so other MEP's keep my existence), while connectivity
check is outwards (I check connectivity of others). Is my
understanding correct, if so could the differences be made clearer
here?

4. The document talks about

        . Supervision of Packet loss measurement in both directions
          of the bidirectional connection;
The MPLS-TP requirement document states that

   31  MPLS-TP MUST support both unidirectional and bidirectional point-
         to-point transport paths.

The NM document does not talk about Unidirection P2P or P2MP paths.

5. I was unclear of the requirement

        . Supervision of Route tracing;

6. There is no talk of protection at all though 1+1 and 1:n protection
is a MUST according the the base requirement. Should that be allowed
to be configurable by the NM?

7. Should the exact definition of unavailable time be defined at all
i.e. 10 seconds etc?

Thanks,
Vishwas

On Fri, Jan 23, 2009 at 2:32 AM, Lam, Hing-Kam (Kam)
<[email-masked]> wrote:
> Vishwas,
>
>
>
> Thanks for your comments. We have discussed your comments among the editors
> and also in the MEAD meeting on Thursday and decided on the following:
>
>
>
> #1
>
> Yes, that is a typo. To simply the text, we decided to remove the mentioning
> of "section 4.5".
>
>
>
> #2 & #3
>
> The second and third dash items of section 8.1.1 have been modified, along
> with other modifications, as follow:
>
> -     Authentication – allow management connectivity only from authenticated
> entities
>
> awareness of the DDOS as an issue and to not provide an exhaustive list of
> mechanisms to implement DDOS.  If there is further text or more examples you
> would like to see added to the section, please provide suggested text.
>
>
>
> #6
>
> Loss ratio has been added to section 7.2.2. By the way, to better reflect
> the intent of this section, its heading has been change from "Collection
> Granularity" to "Measurement Scope"; and in the text, the word "collection"
> has also been changed to "measurement".
>
>
>
> #7
>

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Fri, 23 Jan 2009 20:19:18 -0600

Vishwas,

Thanks again! 

Please see inline below.

Regards,

Kam

> From: Vishwas Manral [mailto:[email-masked]]

> Sent: Friday, January 23, 2009 2:03 PM

> To: Lam, Hing-Kam (Kam)

> Cc: Eric Gray; [email-masked]

> Thanks Kam.

>       MPLS-TP NE is connected indirectly to an OS

[Lam, Hing-Kam (Kam)] In the MEAD discussion earlier this week, we did
have a comment requesting to define the term OS. A definition will be
provided. Anyhow, often OS (Operations System) and OSS (Operations
Support System) are used interchangeably. Examples of OS (or OSS) are
EMS (Element Management System) and NMS (Network Management System).

> superset of the MCN.

[Lam, Hing-Kam (Kam)] Yes, as defined in the draft, a DCN supporting
management plane communication is referred to as a Management
Communication Network (MCN). Depends on the context of the sentence (or
paragraph) in the draft, sometime we use one or the other. If you notice
any specific place that should be changed, please let us know.

> here?

[Lam, Hing-Kam (Kam)] As stated in the above two bullets, continuity
check is about detecting whether or not the connection is broken
(regardless of the connection is the right one (or intended one)); and
connectivity check is about checking if the connection is the right one
or not (of course the precondition is that the connection is not
broken). Note that checking of continuity and connectivity are basic
requirements in the current OAM Requirement draft. The above two bullets
are management requirements to supervise (manage) these OAM functions. 

> The NM document does not talk about Unidirection P2P or P2MP paths.

[Lam, Hing-Kam (Kam)] Yes, the draft should cover unidirectional
connection too. 

>         . Supervision of Route tracing;

[Lam, Hing-Kam (Kam)] This is the supervision (management) of the route
tracing (i.e. route determination) OAM function. Route determination is
an OAM function required by the current OAM Requirement draft. May be we
should change "tracing" to "determination" to align with the OAM
requirement draft.

> to be configurable by the NM?

[Lam, Hing-Kam (Kam)] The current NM requirement draft doesn't
explicitly call out the specific protection schemes, namely 1+1 and 1:n.
Probably we should (could). Any opinions from other?

> i.e. 10 seconds etc?

[Lam, Hing-Kam (Kam)] The current draft already has the definition of
Unavailable Time (UAT), which is defined based on 10-second (see Section
7.1). We need to give the definition of UAS though, i.e., Unavailable
Seconds (UAS) is the count of number of seconds within the UAT period.

> editors

> mentioning

> along

> authenticated

> > mechanisms to implement DDOS.  If there is further text or more
examples

> you

> reflect

> > Granularity" to "Measurement Scope"; and in the text, the word

> "collection"

> >> On Sat, Jan 17, 2009 at 10:20 AM, Eric Gray
<[email-masked]>

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Fri, 23 Jan 2009 20:28:06 -0600

Eric & Scott,

May I now have the token? I would like to update based on my response to
Vishwas.

Regards,

Kam

From: Lam, Hing-Kam (Kam) 
Sent: Friday, January 23, 2009 9:19 PM
To: Vishwas Manral
Cc: Eric Gray; [email-masked]
Subject: RE: [mpls-tp] There is a new MPLS-TP NM Requierements draft

Vishwas,

Thanks again! 

Please see inline below.

Regards,

Kam

examples

<[email-masked]>