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

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

Martin,

Martin Vigoureux wrote:
 > Loa,
 >
 > as stated in my reply to Carlos I understood your e-mail
 > as being Channel Type specific, thus my answer.

ok - that is understood and well

 > We could think about having an error code as you propose below, but it
 > remains a generic procedure,

yes - you receive something over a working associated channel that
you don't understand, thus a "generic discard" or a generic response.

It would be simplest to change the paragraph we are talking about
slightly:

"An LER, LSR or PE MUST discard received G-ACH packets if it is not
G-ACH capable, if it receives packets indicating a G-ACH channel
type that it can't process, if it is not capable of processing
packets on the indicated G-ACH channel, or if...",

Assuming that we want to discard packets in all cases.

/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: Stewart Bryant <[email-masked]>
Date: Wed, 07 Jan 2009 15:28:29 +0000

> Assuming that we want to discard packets in all cases.
First I think that we need to be careful to make a distinction between 
what you do if you do not understand an ACH (channel) type, and what you 
do if you do understand the ACH type, but have some problem with the packet.

The former case is what we are trying to define here, the later case is 
completely out of scope here - but must be specified by the designer of 
the protocol that runs over the ACH.

So the text of the para might be better expressed as:

An LER, LSR or PE MUST discard received G-ACH packets if

1) It is not G-ACH capable, or
2) It is not capable of processing packets on the indicated G-ACH type, or
3) 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. 

When discarding a received G-ACH packet for any of the reasons above, an 
LER, LSR or PE MAY increment an error counter. It MAY also issue a 
system and/or SNMP notification, but the definition such notifications 
are outside the scope of this document.

The definition of actions to be taken on a packet with a G-ACH type for 
which the equipment is configured are outside the scope of this document.

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Jan 2009 17:10:10 +0100

Stewart,

If an LSR is not capable to process G-ACH then it should simply pass through
these packets. Such LSR passes through a MPLS-TP tunnel LSP and could have
had an MPLS-TP tunnel MIP function. As it does not have such tunnel MIP
function it **must** pass through the packets with a G-ACH header.

On a LER or PE that terminates the MPLS-TP tunnel LSP, any not processed
MPLS-TP tunnel LSP OAM packet must be discarded when the PW/VPLS instances
are demultiplexed from the tunnel.

Similarly, any LSR, LER or PE that terminates the MPLS-TP Section LSP must
discard any not processed MPLS-TP Section LSP OAM packets at the point where
the MPSL-TP tunnel LSPs are demultiplexed from the section.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: woensdag 7 januari 2009 16:28
To: Loa Andersson
Cc: VIGOUREUX MARTIN; [email-masked]
Subject: Re: [mpls-tp] Working Group Last Call on
draft-ietf-mpls-tp-gach-gal-01

Loa Andersson wrote:
> Martin,
>
> Martin Vigoureux wrote:
> > 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,
>
> yes - you receive something over a working associated channel that you 
> don't understand, thus a "generic discard" or a generic response.
>
> G-ACH capable, if it receives packets indicating a G-ACH channel type 
> that it can't process, if it is not capable of processing packets on 
> the indicated G-ACH channel, or if...",
>
First I think that we need to be careful to make a distinction between what
you do if you do not understand an ACH (channel) type, and what you do if
you do understand the ACH type, but have some problem with the packet.

The former case is what we are trying to define here, the later case is
completely out of scope here - but must be specified by the designer of the
protocol that runs over the ACH.

1) It is not G-ACH capable, or
2) It is not capable of processing packets on the indicated G-ACH type, or
3) 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. 

When discarding a received G-ACH packet for any of the reasons above, an
LER, LSR or PE MAY increment an error counter. It MAY also issue a system
and/or SNMP notification, but the definition such notifications are outside
the scope of this document.

Stewart

---

From: "BOCCI Matthew" <[email-masked]>
Date: Wed, 7 Jan 2009 17:16:09 +0100

Maarten,

The LSR won't see the ACH unless it is a MEP or a MIP for that LSP, so
it will indeed just forward the packet. 

However, if it is a MEP or a MIP then it will inspect the ACH and the
procedures that Stewart describes below apply.

Matthew

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 07 January 2009 16:10
> To: [email-masked]; 'Loa Andersson'
> Subject: Re: [mpls-tp] Working GroupLast Call on 
> If an LSR is not capable to process G-ACH then it should 
> simply pass through these packets. Such LSR passes through a 
> MPLS-TP tunnel LSP and could have had an MPLS-TP tunnel MIP 
> function. As it does not have such tunnel MIP function it 
> **must** pass through the packets with a G-ACH header.
> 
> On a LER or PE that terminates the MPLS-TP tunnel LSP, any 
> not processed MPLS-TP tunnel LSP OAM packet must be discarded 
> when the PW/VPLS instances are demultiplexed from the tunnel.
> 
> Similarly, any LSR, LER or PE that terminates the MPLS-TP 
> Section LSP must discard any not processed MPLS-TP Section 
> LSP OAM packets at the point where the MPSL-TP tunnel LSPs 
> are demultiplexed from the section.
> 
> Regards,
> Maarten
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> First I think that we need to be careful to make a 
> distinction between what you do if you do not understand an 
> ACH (channel) type, and what you do if you do understand the 
> ACH type, but have some problem with the packet.
> 
> The former case is what we are trying to define here, the 
> later case is completely out of scope here - but must be 
> specified by the designer of the protocol that runs over the ACH.
> 
> 3) It has not, through means outside the scope of this 
> document, indicated to the sending LSR, LER or PE that
> When discarding a received G-ACH packet for any of the 
> reasons above, an LER, LSR or PE MAY increment an error 
> counter. It MAY also issue a system and/or SNMP notification, 
> but the definition such notifications are outside the scope 
> of this document.
> 
> The definition of actions to be taken on a packet with a 
> G-ACH type for which the equipment is configured are outside

---

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

Maarten Vissers wrote:
> these packets. 
Maarten

What on earth do you mean?

If the packet is not addressed to you (by label or by TTL expiry) MPLS 
requires that it me transparently forwarded towards its destination 
without further inspection.

If the packet is addressed to you and you don't know what to do with it 
then you have to drop it.

If you are considering the case of a packet ON and ACH you do 
understand, but with content that you do not understand, then you take 
the action triggered by the ACH type. If that is simply to forward the 
packet on a well defined path the  fine, but that is not with the scope 
of this draft.

> Such LSR passes through a MPLS-TP tunnel LSP and could have
I can't quite parse what you say here, but I think you are considering 
the case of an LSP running over an ACH channel - something many of us 
would be concerned about. If such a construct existed then provided the 
local action programmed for that ACH type was to forward the packet, 
than that is what would happen. However that is not what this draft is 
about.

> are demultiplexed from the tunnel.
What do you mean by not processed? If they are not recognised yes. If 
they are recognised, they must take the action defined by their protocol.
> the MPSL-TP tunnel LSPs are demultiplexed from the section.
Same as above

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Thu, 08 Jan 2009 11:43:51 +0100

Stewart,

I will not reiterate this much more, but
Stewart Bryant wrote:
<snip>

> do if you do understand the ACH type, but have some problem with the 

yes - agrees
> the protocol that runs over the ACH.

yes agree
> 2) It is not capable of processing packets on the indicated G-ACH type, or

is the LSR in 2) not capable of processing packets because either
        a) the first 16 bits are malformed; or
        b) the channel type is not in use

?

If that is so I agree

/Loa

-- 

Loa Andersson

---

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

Stewart,

The text in the draft is very generic and the text proposal you made
> 1) It is not G-ACH capable, or
is also much too generic in my opinion. I.e. an LSR, LER or PE that is not
G-ACH capable must in a number of cases pass through packets with a G-ACH
inside.

What I tried to indicate is that there are many other preconditions to meet
before a packet with a G-ACH field is to be discarded. I.e. the text "it is
not G-ACH capable" can **not** be used in my opinion.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: woensdag 7 januari 2009 17:35
To: Maarten Vissers
Cc: 'Loa Andersson'; 'VIGOUREUX MARTIN'; [email-masked]
Subject: Re: [mpls-tp] Working Group Last Call on

Maarten Vissers wrote:
> Stewart,
>
> If an LSR is not capable to process G-ACH then it should simply pass 
> through these packets.
Maarten

If the packet is not addressed to you (by label or by TTL expiry) MPLS
requires that it me transparently forwarded towards its destination without
further inspection.

If the packet is addressed to you and you don't know what to do with it then
you have to drop it.

If you are considering the case of a packet ON and ACH you do understand,
but with content that you do not understand, then you take the action
triggered by the ACH type. If that is simply to forward the packet on a well
defined path the  fine, but that is not with the scope of this draft.

> Such LSR passes through a MPLS-TP tunnel LSP and could have had an 
> MPLS-TP tunnel MIP function. As it does not have such tunnel MIP 
I can't quite parse what you say here, but I think you are considering the
case of an LSP running over an ACH channel - something many of us would be
concerned about. If such a construct existed then provided the local action
programmed for that ACH type was to forward the packet, than that is what
would happen. However that is not what this draft is about.

> On a LER or PE that terminates the MPLS-TP tunnel LSP, any not 
> processed MPLS-TP tunnel LSP OAM packet must be discarded when the 
> PW/VPLS instances are demultiplexed from the tunnel.
>   
What do you mean by not processed? If they are not recognised yes. If they
are recognised, they must take the action defined by their protocol.
> Similarly, any LSR, LER or PE that terminates the MPLS-TP Section LSP 
> must discard any not processed MPLS-TP Section LSP OAM packets at the 
> point where the MPSL-TP tunnel LSPs are demultiplexed from the section.
>   
Same as above

Stewart
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> what you do if you do not understand an ACH (channel) type, and what 
> you do if you do understand the ACH type, but have some problem with the
packet.
>
> The former case is what we are trying to define here, the later case 
> is completely out of scope here - but must be specified by the 
> designer of the protocol that runs over the ACH.
>
> When discarding a received G-ACH packet for any of the reasons above, 
> an LER, LSR or PE MAY increment an error counter. It MAY also issue a 
> The definition of actions to be taken on a packet with a G-ACH type 
> for which the equipment is configured are outside the scope of this
document.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 08 Jan 2009 12:41:07 +0000

Loa Andersson wrote:
>> First I think that we need to be careful to make a distinction 
>> between what you do if you do not understand an ACH (channel) type, 
>> and what you do if you do understand the ACH type, but have some 
>> problem with the packet.
>
> yes - agrees
>>
If the type is incorrect, and it is a type the LSR is not processing the 
pkt will be dropped
If the type is incorrect and it IS a type that the LSR is processing the 
error will have to be caught in the packet parser for the claimed type.

This is normal pkt parsing.
>        b) the channel type is not in use
I think that this is covered by my answer to (a) but we can add in a 
trap for that as well if you wish

So I think we agree on the actions, and I am fine if the authors wish to 
clarify the text accordingly (I am not an author :) )

Stewart

>> system and/or SNMP notification, but the definition such 
>> notifications are outside the scope of this document.
>>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 08 Jan 2009 17:12:42 +0100

Stewart,

Stewart Bryant wrote:

please help 'cause I don't grok

<snip>
> If the type is incorrect, and it is a type the LSR is not processing the 

hmmm - tentatively yes, but I think that the sentence is Ourobouros in
nature. The type is incorrect therefore it is not processes, the  "and
it is a type the LSR is not processing" is redundant. Isn't it?

> error will have to be caught in the packet parser for the claimed type.

don't understand! You have a channel type field that is incorrect, how 
can you decide that it is something you need to process? Just drop!

The channel *type* field is a 16 bit field, giving us an awful lot of
channel possibilities :) , but what can be wrong with the the type
field other than that the channel type value is not in use?

/Loa

-- 

Loa Andersson

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Jan 2009 10:10:27 +0100

The current proposal 
- to deploy the GAL only with MPLS-TP LSP OAM and not with MPLS-TP PW OAM,
and 
- to deploy regular label stacking as a means to implement TCM
introduces a necessity to configure in TCM end points and in tunnel
endpoints on a per-client signal basis a BottomOfStack (BOS) mode.

At those TCM and tunnel endpoints (i.e. at the MEP functions) it is
necessary to insert an alarm suppression signal under signal fail condition.
If the client is a MPLS-TP PW (MPLS-TP Channel network connection) signal,
then the MPLS-TP alarm suppression OAM signal must contain the ACH (without
GAL). If the client is a MPLS-TP LSP (e.g. PW with TCM or tunnel), then the
MPLS-TP alarm suppression OAM signal must contain the G-ACH with GAL.

This implies that in the MPLS-TP Channel TCM MEP functions and the MPLS-TP
Path NCM MEP functions (terminating the tunnel) it is necessary to configure
per client signal (1 in TCM MEP, n in NCM MEP) if this client is running
BottomOfStack (PW) OAM or Non-BottomOfStack (LSP) OAM. 

I am not sure if it was the intention of the ACH, G-ACH and GAL based
MPLS-TP OAM design to introduce such BOS/NBOS (PW/LSP) OAM configuration in
MPLS-TP TCM MEP and NCM MEP functions?

If it was not the intention and if such is considered undesired, it is
possible to design a MPLS-TP OAM frame format that does not have this side
effect and is less complex then the current design.

Regards,
Maarten

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 12 Jan 2009 11:01:30 +0100

Maarten,

I agree with Stewart. I think the confusion is due to some different
underlying interpretation.

I will try to furhter detail the behavior of different nodes so people
can amend my understanding.

Intermediate nodes (e.g. LSR for LSPs or S-PE for PWs) usually pass
through (forward) OAM packets purely on the basis of the MPLS label that
preceeds the GAL/G-ACH (e.g. the LSP label or the PW label). This
behavior ensures that OAM packets fate share with user data packets. The
GAL/G-ACH is never exposed in these intermediate nodes.

The only exception to this rule is when the TTL expires on an
intermediate node. In this case the packet MUST not be forwarded and it
can either be processed or dropped by the node. If such an intermediate
node is G-ACH capable and recognizes the ACH channel type, it MUST
process the packet as a MIP. Section 4 describes what such an
intermediate node has to do if either is not G-ACH capable or it does
not recognize the ACH channel type.

Terminating nodes (e.g. LER for LSPs or T-PE for PWs) will forward user
data packets at the client layer network and terminate all the received
OAM packets in the MEP. If the terminating nodes is G-ACH capable and
recognizes the ACH channel type, it MUST process the packet as a MEP.
Section 4 describes what the terminating node has to do if either is not
G-ACH capable or it does not recognize the ACH channel type.

As a consequence Stewart is right. When the G-ACH gets exposed for
processing in a node, the packet cannot be forwarded. It can either be
processed or dropped.

Italo

> Sent: Thursday, January 08, 2009 1:08 PM
> To: [email-masked]
> Cc: [email-masked]; VIGOUREUX MARTIN
> simply pass 
> understand,
> Section LSP 
> distinction between 
> later case 
> reasons above,

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jan 2009 14:37:28 +0100

Italo,

In my opinion we should not use "G-ACH capable" or "not G-ACH capable" as a
condition in our specifications. These conditions are too ambiguous. OAM
processing is determined by the type of MIP and MEP functions
present/absent. For MPLS-TP OAM the presence/absence of a MPLS-TP (PW,
Tunnel, Section) MIP or MEP function determines the behaviour of the port
units in a node. Some port units may support MPLS-TP MEP and/or MIP
funcitons, other port units in the same node may not support such functions.

See inline for some detailed comment...

-----Original Message-----
From: BUSI ITALO [mailto:[email-masked]] 
Sent: maandag 12 januari 2009 11:02
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; VIGOUREUX MARTIN
Subject: RE: [mpls-tp] Working GroupLast Call on

Maarten,

I will try to furhter detail the behavior of different nodes so people can
amend my understanding.

Intermediate nodes (e.g. LSR for LSPs or S-PE for PWs) usually pass through
(forward) OAM packets purely on the basis of the MPLS label that preceeds
the GAL/G-ACH (e.g. the LSP label or the PW label). This behavior ensures
that OAM packets fate share with user data packets. The GAL/G-ACH is never
exposed in these intermediate nodes.

[mv] MPLS-TP Section OAM is terminated in all MPLS-TP Path (Tunnel) and
Channel (PW) switching nodes, including "intermediate nodes". If MPLS-TP
Section MEP function is present on a port, then this will terminate this
OAM, otherwise the tunnel demultiplexing adaptation function will discard
such OAM. The Section G-ACH/GAL is as such exposed in these intermediate
nodes.

[mv] MPLS-TP Path (tunnel) switching nodes will typically contain MPLS-TP
Path MIP functions on its port units. Those Path MIP functions will inspect
all MPLS-TP tunnel packets to see if it includes MPLS-TP tunnel OAM that is
destined for the MIP. I.e. every packet in a tunnel signal is checked for
"OuterLSE.S=0 and InnerLSE.LBL=13 and InnerLSE.S=1 and Nibble=0001 and
ChannelType=XXX".

[mv] MPLS-TP Channel (PW) TCM OAM is not checked for in path switching
nodes.

[mv] MPLS-TP Channel (PW) switching nodes will typically contain MPLS-TP
Path MEP functions on its port units and MPLS-TP Channel MIP funcitons. The
Path MEP functions check all MPLS-TP tunnel packets to see if it includes
MPLS-TP tunnel OAM that is destined for the MEP. I.e. every packet in a
tunnel signal is checked for
"OuterLSE.S=0 and InnerLSE.LBL=13 and InnerLSE.S=1 and Nibble=0001 and
ChannelType=XXX".
The Channel MIP functions will inspect all MPLS-TP channel packets to see if
it includes either MPLS-TP Channel TCM OAM, or MPLS-TP channel NCM OAM that
is destined for the MIP. I.e. every packet in a channel signal is checked
for either 
(case of TCM) "OuterLSE.S=0 and InnerLSE.LBL=13 and InnerLSE.S=1 and
Nibble=0001 and ChannelType=XXX", or
(case of NCM) "OuterLSE.S=1 and Nibble=0001 and ChannelType=XXX".
MPLS-TP channel TCM MEP functions may also be present to support e.g. SNCP
or admin domain monitoring. Such MEP functions will also perform this
checking on all packets.

[mv] I hope this clarifies that your statement "The GAL/G-ACH is never
exposed in these intermediate nodes." is not correct.

The only exception to this rule is when the TTL expires on an intermediate
node. In this case the packet MUST not be forwarded and it can either be
processed or dropped by the node. If such an intermediate node is G-ACH
capable and recognizes the ACH channel type, it MUST process the packet as a
MIP. Section 4 describes what such an intermediate node has to do if either
is not G-ACH capable or it does not recognize the ACH channel type.

[mv] If a port unit receives an MPLS-TP OAM packet of which the TTL expires,
and if this port unit is does not support a MPLS-TP MEP or MIP to process
such OAM packet, then this MPLS-TP OAM packet with expired TTL is discarded.
To me this is a very different statement then in section 4.

Terminating nodes (e.g. LER for LSPs or T-PE for PWs) will forward user data
packets at the client layer network and terminate all the received OAM
packets in the MEP. If the terminating nodes is G-ACH capable and recognizes
the ACH channel type, it MUST process the packet as a MEP.
Section 4 describes what the terminating node has to do if either is not
G-ACH capable or it does not recognize the ACH channel type.

[mv] Again, the node may have many MPLS-TP MEP and MIP functions that are
capable to process MPLS-TP OAM packets, but if there is one port unit which
is not supporting such MEP/MIP funcitons, then the node is G-ACH capable
(i.e. support MPLS-TP MEP/MIP funcitons), but this specific port unit is not
capable to process the MPLS-TP OAM packet as it is lacking support of the
necessary MEP/MIP function.

[mv] G-ACH get's never directly exposed in a node as there will always be a
GAL infront of it. 
If there is no MPLS-TP MIP or MEP function, then there is no checking for
MPLS-TP OAM; i.e. no checking for e.g. "OuterLSE.S=0 and InnerLSE.LBL=13 and
InnerLSE.S=1 and Nibble=0001 and ChannelType=XXX".
If there is a demultiplexer function, then all MPLS-TP packets with a label
in the range 0-15 at this point in the processing will not be forwarded to
one of the client output ports; there is no specific label 13 checking or
G-ACH checking necessary.
If the TTL of a MPLS-TP OAM packet expires and there is no MPLS-TP MIP or
MEP function, then the GAL (label 13) will be an undefined label and the
packet is dropped.

In none of these cases the presence of a G-ACH field in a packet is checked.

Regards,
Maarten

Italo

> is also much too generic in my opinion. I.e. an LSR, LER or PE that is 
> not G-ACH capable must in a number of cases pass through packets with 
> a G-ACH inside.
> 
> What I tried to indicate is that there are many other preconditions to 
> meet before a packet with a G-ACH field is to be discarded. I.e.
> the text "it is
> If the packet is addressed to you and you don't know what to do with 
> it then you have to drop it.
> 
> packet on a well defined path the  fine, but that is not with the 
> scope of this draft.
> 
> 
> would be concerned about. If such a construct existed then provided 
> the local action programmed for that ACH type was to forward the 
> packet, than that is what would happen. However that is not what this 
> draft is about.
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 13 Jan 2009 16:41:54 +0100

Maarten,

I think there are few points of misunderstanding.

This draft has is applicable to MPLS in general and not only to MPLS-TP.

I think that a "not G-ACH capable" is an existing MPLS device that does
not support this draft.

I think the case where the node is "G-ACH capable" (i.e. it is an
MPLS-TP node or an MPLS node that supports this draft) but it has not
MEP/MIP on that unit port is covered by the case "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" in section 4.

I also think there is some misunderstanding in the way MEP/MIP
capabilities works with MPLS-TP. See further in line marked with [ib2]

Italo

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Tuesday, January 13, 2009 2:37 PM
> To: BUSI ITALO; [email-masked]

[ib2] Your are partially right. I described only LSP and PW cases. In
the case of Section, each MPLS-TP node is actually a terminating node
for the Section (i.e. the GAL/G-ACH gets exposed at the Section
terminating point). Also in this case the Section OAM must be either
processed or dropped by the node and MUST NOT be forwarded.

> "OuterLSE.S=0 and InnerLSE.LBL=13 and InnerLSE.S=1 and Nibble=0001 and

[ib2] I disagree. MPLS-TP Path (tunnel) MIP functions will process only
the OAM packets where the TTL expires. All the other packets (both user
data and OAM at the Path level) are forwarded transparently. The OAM
packets with TTL expiry are other processed by the MIP or dropped.

> [mv] MPLS-TP Channel (PW) TCM OAM is not checked for in path switching

[ib2] I agree.

> "OuterLSE.S=0 and InnerLSE.LBL=13 and InnerLSE.S=1 and Nibble=0001 and

[ib2] I agree. The Path MEP either processes or drops packet received
with the LSP label followed by the GAL/G-ACH. This is a terminating node
for the LSP.

> or admin domain monitoring. Such MEP functions will also perform this

[ib2] I disagree. MPLS-TP Channel (PW) MIP functions will process only
the OAM packets where the TTL expires. All the other packets (both user
data and OAM at the Path level) are forwarded transparently. The OAM
packets with TTL expiry are other processed by the MIP or dropped.

> intermediate

[ib2] What is the difference? Section 4 says that the packet is
discarded.

> necessary MEP/MIP function.

[ib2] Are you considering the case of a node that is G-ACH capable for
some port units and not G-ACH capable on other port units?

> In none of these cases the presence of a G-ACH field in a 

[ib2] Maybe rather than "exposed" I should have used "parsed". In a
nutshell only terminating nodes or intermediate nodes where the TTL
expires parses the GAL/G-ACH and in this case they either process or
drop the packet. Intermediate nodes where the TTL does not expire,
forwards the packet without looking at the G-ACH.

> G-ACH type

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Jan 2009 16:33:18 +0000

I agree with Italo here.

The only circumstance in which a node gets to look below the top label is
when the outer label indicates that it terminates there or when TTL expires.

I suppose we could also usefully allow an LSR (in the slow path) to
check for label 13 when it does not have the top label in its LFIB.

However any requirement to look beyond the top label in the fast path
is not MPLS.

Stewart

BUSI ITALO wrote:
>>> is also much too generic in my opinion. I.e. an LSR, LER or 
>>>       
>> PE that is 
>>     
>>> not G-ACH capable must in a number of cases pass through 
>>>       
>> packets with 
>>     
>>> a G-ACH inside.
>>>
>>> What I tried to indicate is that there are many other 
>>>       
>> preconditions to 
>>     
>>> If the packet is not addressed to you (by label or by TTL 
>>>       
>> expiry) MPLS 
>>     
>>> If the packet is addressed to you and you don't know what 
>>>       
>> to do with 
>>     
>>> understand, but with content that you do not understand, 
>>>       
>> then you take 
>>     
>>> the action triggered by the ACH type. If that is simply to 
>>>       
>> forward the 
>>     
>>>> Such LSR passes through a MPLS-TP tunnel LSP and could 
>>>>         
>> have had an 
>>     
>>> I can't quite parse what you say here, but I think you are 
>>>       
>> considering 
>>     
>>> the case of an LSP running over an ACH channel - something 
>>>       
>> many of us 
>>     
>>> packet, than that is what would happen. However that is not 
>>>       
>> what this 
>>     
>>> draft is about.
>>>
>>>       
>>>> processed MPLS-TP tunnel LSP OAM packet must be discarded 
>>>>         
>> when the 
>>     
>>> What do you mean by not processed? If they are not 
>>>       
>> recognised yes. If 
>>     
>>>> must discard any not processed MPLS-TP Section LSP OAM
>>>>         
>>> packets at the
>>>       
>>>> point where the MPSL-TP tunnel LSPs are demultiplexed from
>>>>         
>>> the section.
>>>       
>>>>   
>>>>         
>>> Same as above
>>>
>>> Stewart
>>>       
>>>> Regards,
>>>> Maarten
>>>>
>> [mailto:[email-masked]] On 
>>     
>>>> Behalf Of Stewart Bryant
>>>>>> as stated in my reply to Carlos I understood your 
>>>>>>             
>> e-mail as being 
>>     
>>>>>> We could think about having an error code as you propose
>>>>>>             
>>> below, but
>>>       
>>>>> yes - you receive something over a working associated 
>>>>>           
>> channel that 
>>     
>>>>> you don't understand, thus a "generic discard" or a
>>>>>           
>>> generic response.
>>>       
>>>>> "An LER, LSR or PE MUST discard received G-ACH packets if
>>>>>           
>>> it is not
>>>       
>>>>> G-ACH capable, if it receives packets indicating a G-ACH
>>>>>           
>>> channel type
>>>       
>>>>> that it can't process, if it is not capable of processing
>>>>>           
>>> packets on
>>>       
>>>> what you do if you do not understand an ACH (channel) type,
>>>>         
>>> and what
>>>       
>>>> you do if you do understand the ACH type, but have some
>>>>         
>>> problem with the
>>> packet.
>>>       
>>>>    it will process G-ACH packets received on the 
>>>>         
>> indicated channel. 
>>     
>>>> an LER, LSR or PE MAY increment an error counter. It MAY
>>>>         
>>> also issue a
>>>       
>>> notifications
>>>> for which the equipment is configured are outside the 
>>>>         
>> scope of this
>>     
>>> document.
>>>       
>>>> Stewart
>>>>
>>>>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jan 2009 23:49:03 +0100

Italo, Stewart,

> [ib2] Are you considering the case of a node that is G-ACH capable
> for some port units and not G-ACH capable on other port units?

The answer to this question is yes.

I expect that existing installed equipment will be extended with MPLS-TP
port units. You then get a mix of MPLS (without MPLS-TP MEP/MIP functions)
and MPLS-TP port units (with MPLS-TP MEP/MIP funtions). The node is then
G-ACH capable for some ports and non-G-ACH capable for other ports.

> I also think there is some misunderstanding in the way MEP/MIP
capabilities
> works with MPLS-TP. See further in line marked with [ib2]

The answer is again yes. After reading both your replies I notice that I had
still the T-MPLS OAM behaviour in mind instead of the MPLS-TP OAM behaviour
with label stacking for TCM. The pecularity of this new behaviour is that
e.g. the MPLS-TP channel layer connection does not terminate in a channel
TCM MEP, but the label identifying this tandem connection does terminate.

If I would reuse the 802.1ag MEP direction indications of "Up MEP" and "Down
MEP", then an interface port on a PE node may contain the following MEPs:
- for every MPLS-TP Channel (PW) there is 1 MPLS-TP Up MEP, 1 MPLS-TP MIP
and 2 MPLS-TP Down MEPs
- for every VPLS there is 1 ETH Up MEP, 1 ETH MIP and 3 MPLS-TP Down MEPs
- for every MPLS-TP path (Tunnel) - carrying an aggregate of PW and VPLS
instances - there is 1 MPLS-TP Down MEP
- for the Section there is 1 MPLS-TP Down MEP.

As Stewart indicates 
"The only circumstance in which a node gets to look below the top label is
when the outer label indicates that it terminates there or when TTL
expires."

For this interface port on a PE this implies that there are 
- up to four outer labels that terminate in the ingress port; i.e. for the
  # MPLS-TP Section network connection with Down MEP, 
  # MPLS-TP Path network connection with Down MEP, 
  # first MPLS-TP Channel tandem connection with Down MEP, and
  # second MPLS-TP channel tandem connection with Down MEP
- one times an outer label that terminate in the egress port (per MPLS-TP
channel); i.e. for the
  # third MPLS-TP Channel tandem connection with Up MEP
- one potential TTL expiry in the ingress and egress port per MPLS-TP
channel); i.e. for the 
  # MPLS-TP Channel MIP.

Sect.NC   Path NC   Chan.TC1   Chan.TC2
-------   -------   -------    -------
| GAL |   | LBL |   | LBL |    | LBL | <- GAL and tunnel labels terminate
-------   -------   -------    -------
| OAM |   | GAL |   | LBL |    | LBL | <- GAL and TC1 labels terminate
-------   -------   -------    -------
          | OAM |   | GAL |    | LBL | <- GAL and TC2 labels terminate
          -------   -------    -------
                    | OAM |    | GAL | <- GAL label terminates
                    -------    -------
                               | OAM |
                               -------

Figure 1 - PE Ingress port terminating labels

Chan.TC3
------- 
| LBL | <- TC3 label terminates
-------
| GAL | <- Gal label terminates
-------
| OAM |
-------

Figure 2 - PE Egress port terminating labels

Is it correct that the LFIB will contain in this case the GAL, tunnel, TC1,
TC2 and TC3 labels as terminating labels?

Regards,
Maarten

-----Original Message-----
From: BUSI ITALO [mailto:[email-masked]] 
Sent: dinsdag 13 januari 2009 16:42
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; VIGOUREUX MARTIN
Subject: RE: [mpls-tp] Working GroupLast Call on

Maarten,

I think that a "not G-ACH capable" is an existing MPLS device that does not
support this draft.

I think the case where the node is "G-ACH capable" (i.e. it is an MPLS-TP
node or an MPLS node that supports this draft) but it has not MEP/MIP on
that unit port is covered by the case "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" in section 4.

I also think there is some misunderstanding in the way MEP/MIP capabilities
works with MPLS-TP. See further in line marked with [ib2]

Italo

> In my opinion we should not use "G-ACH capable" or "not G-ACH capable" 
> as a condition in our specifications. These conditions are too 
> ambiguous. OAM processing is determined by the type of MIP and MEP 
> functions present/absent. For MPLS-TP OAM the presence/absence of a 
> MPLS-TP (PW, Tunnel, Section) MIP or MEP function determines the 
> behaviour of the port units in a node. Some port units may support 
> MPLS-TP MEP and/or MIP funcitons, other port units in the same node 
> may not support such functions.
> 
> through
> (forward) OAM packets purely on the basis of the MPLS label that 
> behavior ensures that OAM packets fate share with user data packets. 
> The GAL/G-ACH is never exposed in these intermediate nodes.
> 
> Section MEP function is present on a port, then this will terminate 
> this OAM, otherwise the tunnel demultiplexing adaptation function will 
> discard such OAM. The Section G-ACH/GAL is as such exposed in these 
> intermediate nodes.
> 

[ib2] Your are partially right. I described only LSP and PW cases. In the
case of Section, each MPLS-TP node is actually a terminating node for the
Section (i.e. the GAL/G-ACH gets exposed at the Section terminating point).
Also in this case the Section OAM must be either processed or dropped by the
node and MUST NOT be forwarded.

> [mv] MPLS-TP Path (tunnel) switching nodes will typically contain 
> MPLS-TP Path MIP functions on its port units. Those Path MIP functions 
> will inspect all MPLS-TP tunnel packets to see if it includes MPLS-TP 
> tunnel OAM that is destined for the MIP. I.e. every packet in a tunnel 
> signal is checked for "OuterLSE.S=0 and InnerLSE.LBL=13 and 

[ib2] I disagree. MPLS-TP Path (tunnel) MIP functions will process only the
OAM packets where the TTL expires. All the other packets (both user data and
OAM at the Path level) are forwarded transparently. The OAM packets with TTL
expiry are other processed by the MIP or dropped.

[ib2] I agree.

> [mv] MPLS-TP Channel (PW) switching nodes will typically contain 
> MPLS-TP Path MEP functions on its port units and MPLS-TP Channel MIP 
> funcitons. The Path MEP functions check all MPLS-TP tunnel packets to 
> see if it includes MPLS-TP tunnel OAM that is destined for the MEP. 
> I.e. every packet in a tunnel signal is checked for "OuterLSE.S=0 and 
> InnerLSE.LBL=13 and InnerLSE.S=1 and Nibble=0001 and ChannelType=XXX".

[ib2] I agree. The Path MEP either processes or drops packet received with
the LSP label followed by the GAL/G-ACH. This is a terminating node for the
LSP.

> The Channel MIP functions will inspect all MPLS-TP channel packets to 
> see if it includes either MPLS-TP Channel TCM OAM, or MPLS-TP channel 
> NCM OAM that is destined for the MIP. I.e. every packet in a channel 
> signal is checked for either (case of TCM) "OuterLSE.S=0 and 
> InnerLSE.LBL=13 and InnerLSE.S=1 and
> MPLS-TP channel TCM MEP functions may also be present to support e.g. 
> SNCP or admin domain monitoring. Such MEP functions will also perform 
> this checking on all packets.
> 

[ib2] I disagree. MPLS-TP Channel (PW) MIP functions will process only the
OAM packets where the TTL expires. All the other packets (both user data and
OAM at the Path level) are forwarded transparently. The OAM packets with TTL
expiry are other processed by the MIP or dropped.

> intermediate node. In this case the packet MUST not be forwarded and 
> it can either be processed or dropped by the node. If such an 
> intermediate node is G-ACH capable and recognizes the ACH channel 
> type, it MUST process the packet as a MIP. Section 4 describes what 
> such an intermediate node has to do if either is not G-ACH capable or 
> it does not recognize the ACH channel type.
> 
> [mv] If a port unit receives an MPLS-TP OAM packet of which the TTL 
> expires, and if this port unit is does not support a MPLS-TP MEP or 
> MIP to process such OAM packet, then this MPLS-TP OAM packet with 
> expired TTL is discarded.

[ib2] What is the difference? Section 4 says that the packet is discarded.

> 
> Terminating nodes (e.g. LER for LSPs or T-PE for PWs) will forward 
> user data packets at the client layer network and terminate all the 
> received OAM packets in the MEP. If the terminating nodes is G-ACH 
> capable and recognizes the ACH channel type, it MUST process the 
> packet as a MEP.
> Section 4 describes what the terminating node has to do if either is 
> not G-ACH capable or it does not recognize the ACH channel type.
> 
> [mv] Again, the node may have many MPLS-TP MEP and MIP functions that 
> are capable to process MPLS-TP OAM packets, but if there is one port 
> unit which is not supporting such MEP/MIP funcitons, then the node is 
> G-ACH capable (i.e. support MPLS-TP MEP/MIP funcitons), but this 
> specific port unit is not capable to process the MPLS-TP OAM packet as 
> it is lacking support of the necessary MEP/MIP function.
> 

[ib2] Are you considering the case of a node that is G-ACH capable for some
port units and not G-ACH capable on other port units?

> [mv] G-ACH get's never directly exposed in a node as there will always 
> be a GAL infront of it.
> If there is no MPLS-TP MIP or MEP function, then there is no checking 
> for MPLS-TP OAM; i.e. no checking for e.g. "OuterLSE.S=0 and
> InnerLSE.LBL=13 and
> If there is a demultiplexer function, then all MPLS-TP packets with a 
> label in the range 0-15 at this point in the processing will not be 
> forwarded to one of the client output ports; there is no specific 
> label 13 checking or G-ACH checking necessary.
> If the TTL of a MPLS-TP OAM packet expires and there is no MPLS-TP MIP 
> or MEP function, then the GAL (label 13) will be an undefined label 
> and the packet is dropped.
> 

[ib2] Maybe rather than "exposed" I should have used "parsed". In a nutshell
only terminating nodes or intermediate nodes where the TTL expires parses
the GAL/G-ACH and in this case they either process or drop the packet.
Intermediate nodes where the TTL does not expire, forwards the packet
without looking at the G-ACH.