Subject: [mpls-tp] Y.1731 for MPLS-TP draft

From: Vishwas Manral <[email-masked]>
Date: Wed, 1 Jul 2009 12:58:50 -0700

Hi,

I went through the draft and am seeing the effort required to port
802.1ag and Y.1731 into the MPLS-TP domain. I found that using Y.1731
allows a good reuse of the code (LTM/ LTR ofcourse need to be defined
for MPLS-TP).

That said I had the following top level comments (including the
acronyms of MEP and MIP not matching the ones defined in the
referenced specs) :))

0. My suggestion is to use one channel type for all messages instead
of 1 for each individual type.

1. If the channel type is Y.1731, why do we not allow multiple CFM
PDU's within a single MPLS packet. This will help in scalability. You
can put conditions like 32 bit boundaries if that is so required. With
the way the packet is, we can always pack more data into the packet.
Also no address checking equal to the MD level is done in the
procedure for packets(other than MEP CCM) is performed. Also
equivalent to checks for VLAN identifiers do we need to do it on the
lables is not specified.

2. There is no talk of the functional requirements satisfied by the
document. The entire idea is about packet format alone. So things like
Fault notification, detection, delay measurement etc need to be
elaborated too.

3. CFM uses different MAC addresses for each level. How do we map the
8 different channels in MPLS. If we do not, that needs to be
mentioned.

4. No security mechanism present in the G-ACH header. As each
parameter check failure is treated as connectivity failure, it would
be good to use the information in the document
http://www.ietf.org/internet-drafts/draft-manral-mpls-tp-oam-security-tlv-00.txt
for the purpose.

5. If LTM is not used how is Path discocery and fault isolation done.
As the LTM message carries the target MAC address as part of the
payload it cannot be directly used. Also what needs to be done when an
LTM/ LTR is received needs to be specified.

Informational
-------------------
6. The MEP and MIP definition is not correct. If you look at 802.1ag
you will realize that:

   MEP    MA End Point

   MIP    MD Intermediate Point

Thanks,
Vishwas

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 01 Jul 2009 23:20:47 +0200

Hello Vishwas,

> Informational

Y.1731 and the draft use the ITU-T terminology while
you refer to the IEEE terminology:

ITU-T Y.1731                       IEEE 802.1ag clause 19
----------------------------------------------------------------
Maintenance Entity Group MEG -- Maintenance Association MA
Maintenance Entity ME        -- Maintenance Domain MD
Maintenance Entity level MEL -- Maintenance Domain Level
MEG end point MEP            -- MA end point MEP
MEG intermediate point MIP   -- MA intermediate point MIP

Please note that Y.1731 and IEEE 802.1ag were developed in
close cooperation.

Kind regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 1 Jul 2009 14:46:34 -0700

Hi Hubb,

I actually looked at both. The current draft doesn't seem to match any
of the two 802.1ag and Y.1731.

That said do you have comments on the other questions I have raised?

Thanks,
Vishwas

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 01 Jul 2009 23:58:57 +0200

Hi Vishwas,

I will try to clarify your other comments in line [hvh]

> allows a good reuse of the code (LTM/ LTR ofcourse need to be defined

[hvh] Thank you, of course we need to adapt to MPLS-TP methodology.

> of 1 for each individual type.

[hvh] I do not see the benefit this has, are you afraid that the
channel type space is not large enough (it is 64k).

> PDU's within a single MPLS packet.

[hvh] is this perhaps the reason for allocating a single channel type?

> This will help in scalability. 

[hvh I don't think there is a problem with scalability with a channel
type space of 64k.

> You can put conditions like 32 bit boundaries if that is so required.
 > With the way the packet is, we can always pack more data into the
 > packet.

[hvh] does this apply to both pro-active and on-demand PDU's?

[hvh] if it does, it requires an additional discriminator
process that identifies the individual OAM PDU before they can
be handed off to the appropriate processing function.
If each OAM PDU has its own channel type no discrimination
process is required.

> equivalent to checks for VLAN identifiers do we need to do it on the

[hvh] the CCM verifies the connection, if there is no LOC
detected it is assumed that other OAM PDU's are correctly
addressed.
As soon as LOC is detected other OAM PDU's are discarded
and not processed.

> Fault notification, detection, delay measurement etc need to be

[hvh] the draft is not finished yet

> 8 different channels in MPLS. If we do not, that needs to be

[hvh] we are discussing the addressing scheme in another thread.

[hvh] the levels in Y.1731 are used in case sections of path
are monitored separately, the current assumption for MPL-TP is
to use lable stacking for section monitoring.

> http://www.ietf.org/internet-drafts/draft-manral-mpls-tp-oam-security-tlv-00.txt

[hvh] thanks for the pointer, I will have a look at it.

> LTM/ LTR is received needs to be specified.

[hvh] as mentioned above addressing is discussed.
[hvh] we are working on the definition of the LTM/LTR.

regards, Huub.

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 1 Jul 2009 15:36:59 -0700

Hi Hubb,

Thanks for the reply. I understand the draft has just recently been published.

> channel type space is not large enough (it is 64k).
You have mentioned multiple ways in the draft. By using the same
channel type we are able to pack multiple PDU's togather. The PDU's
can be further decapsulated.

> [hvh] is this perhaps the reason for allocating a single channel type?
No not channel type, but better packet packing.

> [hvh I don't think there is a problem with scalability with a channel
I do not mean the utilization of the 16 bit space. I mean scalability
with respect to lesser number of packets being sent/ received over the
network (think of TCP).

> [hvh] does this apply to both pro-active and on-demand PDU's?
If I know multiple PDU's to go to the same destination, I can as well
pack them togather. We do not need to send a seperate packet. That is
the reason I have asked for a single channel type.

> As soon as LOC is detected other OAM PDU's are discarded
Though we talk about the specification not having Ethernet properties,
reading the spec (especially 802.1ag which talks about packet
processing at a greater detail) the packet processing further requires
checking the ethernet fields.

> [hvh] the draft is not finished yet
Ok. Is there a list where the draft is being discussed? I would be
eager to atleast be part of the discussion, so I know what is comming
and also help do it better.

> to use lable stacking for section monitoring.
Levels are useful not in different levels of the network heirarchy (as
packets will anyway be further tunnelled), but at the same network
level (but layered OAM), so if we get a packet of a lower level I
discard it etc.

If I get you you seem to be talking about using network heirarchies?
Is that correct?

> [hvh] thanks for the pointer, I will have a look at it.
Thanks.

> [hvh] we are working on the definition of the LTM/LTR.
I agree. I am just telling from the top level what I feel are the
differences that need to be done.

Thanks,
Vishwas

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 16 Jul 2009 11:52:15 +0200

Vishwas,

See inline... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vishwas Manral
Sent: woensdag 1 juli 2009 21:59
To: [email-masked]
Subject: [mpls-tp] Y.1731 for MPLS-TP draft

Hi,

I went through the draft and am seeing the effort required to port 802.1ag
and Y.1731 into the MPLS-TP domain. I found that using Y.1731 allows a good
reuse of the code (LTM/ LTR ofcourse need to be defined for MPLS-TP).

That said I had the following top level comments (including the acronyms of
MEP and MIP not matching the ones defined in the referenced specs) :))

0. My suggestion is to use one channel type for all messages instead of 1
for each individual type.

[mv] I assume that you refer to
http://www.ietf.org/internet-drafts/draft-bhh-mpls-tp-oam-y1731-03.txt
section 3 in which the draft presents two encoding options 1 and 2:
1.	Use a single ACH Channel Type (0xXX) identifying the whole Y.1731
toolset and rely upon the OpCode field in Y.1731 to identify the specific
OAM PDU
2.	Use of multiple ACH Channel Type values, one for each OAM PDU thus
making the usage of the OpCode field within the OAM PDU not required when
used in MPLS-TP.

[mv] You supports as such option 1, for which section 3.1 presents the frame
format as copied hereafter:

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|   Y.1731 Channel Type (0xXX)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MEL | Version |    OpCode     |     Flags     |   TLV Offset  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                  OAM function specific fields                 |
   |                         (Y.1731 based)                        |
   +                                                               +
   :                              ...                              :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 1	Y.1731 PDU within a single ACH Channel Type

1. If the channel type is Y.1731, why do we not allow multiple CFM PDU's
within a single MPLS packet. This will help in scalability. You can put
conditions like 32 bit boundaries if that is so required. With the way the
packet is, we can always pack more data into the packet.
Also no address checking equal to the MD level is done in the procedure for
packets(other than MEP CCM) is performed. Also equivalent to checks for VLAN
identifiers do we need to do it on the lables is not specified.

[mv] You ask the question why we do not allow multiple CFM PDUs into a
signle MPSL packet. 
- The rationale for not doing this is that there is typically only one CFM
PDU to send at any point in time.
- If you however look closely at the CCM PDU, then you will notice that this
CCM PDU contains more then one OAM function; i.e. continuity check,
connectivity check, remote defect indication, frame/packet loss measurement.
This list is presented in section 4.1. The CCM PDU as such includes all
pro-active OAM functions that originate from a MEP Source; result is a
single OAM packet per MEP source under normal conditions. 
- The other pro-active OAM PDUs are AIS and LCK PDUs. Those PDUs are
generated from the adaptation functions located at the intermediate points
between the MEPs. I assume that you understadn that it was not possible to
combine those AIS/LCK PDUs with the CCM PDU in one packet/frame.
- The on-demand OAM functions have typically different end points, or
different priority, or different repetition rate then the OAM functions in
the CCM PDU, so it was not possible to combine those on-demand OAM functions
into one PDU (or to combine multiple OAM PDUs (each with one OAM function)
into one packet.
- The protection switching related communcation OAM function (APS) has also
a different generation requirement then the CCM PDU, so it was decided not
to combine it with the OAM functions in the CCM PDU.

[mv] With respect to address checking for MD/MEG level, you should be aware
that G.8021 ignores the MEG/MD level information in the DA field from the
beginning. If you look at the latest version of 802.1Q (including all
amendments), you will notice that also 802.1Q is now ignoring the MD/MEG
level information in the DA. Rationale is that such MEG/MD level information
is not present in ethernet OAM frames that have a unicast MAC address. That
is why g.8021 and now also 802.1Q specify that the MEG/MD level must be
inferred from the MEL field in the PDU.

[mv] For MPLS-TP it was decided to deploy label stacking as MEG/MD level
encoding method. This implies that MEL field can be ignored within MPLS-TP
MEP and MIP functions.

[mv] The value in VLAN Identifier (VID) fields is checked in Ethernet when
"Enable Ingress Filtering" is set to true. When the value in the VID field
does not match any of the VID values registered on that interface port, then
the frame is discarded. This is a function that is outside the OAM space. It
is a **security** function, which prevents that intruders can put alien
frames into the connection. This same **security** function is present when
MPLS-TP deploys "per-interface" label spaces for LSPs and PWs. When MPLS-TP
deploys "per platform" label space then there is a security risk. But again
this is outside the scope of OAM.

2. There is no talk of the functional requirements satisfied by the
document. The entire idea is about packet format alone. So things like Fault
notification, detection, delay measurement etc need to be elaborated too.

[mv] As soon as the OAM requirements document is approved it will be
possible to take draft-bhh-mpls-tp-oam-y1731-03.txt and map it to the OAM
requirements.

3. CFM uses different MAC addresses for each level. How do we map the
8 different channels in MPLS. If we do not, that needs to be mentioned.

[mv] Y.1731/802.1ag CFM frames encode the MEG/MD level in the MEL field. For
some OAM PDUs the MEG/MD level information is also copied into the DA field.
But as indicated above, this information is not used in G.8021 and also
latest amendment to 802.1Q have introduced to use the MEL field instead of
the DA field. In MPLS-TP the MEG/MD level is encoded in the label stack,
removing the need for MEG/MD level encoding in the MEL field (MEL field is
to be ignored in MPLS-TP MEP and MIP functions as such).

4. No security mechanism present in the G-ACH header. As each parameter
check failure is treated as connectivity failure, it would be good to use
the information in the document
http://www.ietf.org/internet-drafts/draft-manral-mpls-tp-oam-security-tlv-00
.txt
for the purpose.

[mv] Security in transport networks is dealt with by 
- the connection (in general transport entity) construct and the
connectivity verification OAM funcction within this connection construct
- the security in the management plane
- the traffic conditioning at the input ports of the transport network and
at input ports of admin domains
- the link security for physical media
- security provided by tandem connection/segment monitoring levels.
Refer to clause 13 in G.8110.1 amendment 1
http://www.itu.int/rec/T-REC-G.8110.1-200707-I!Amd1/en.

[mv] There is as such no need to add additional security checks on OAM PDUs.

5. If LTM is not used how is Path discocery and fault isolation done.
As the LTM message carries the target MAC address as part of the payload it
cannot be directly used. Also what needs to be done when an LTM/ LTR is
received needs to be specified.

[mv] LTM/LTR PDUs are associated with Link Trace fucntion in Ethernet VLANs.
This link trace function checks the registration of a MAC filtering rule
within the VLAN. The link trace function does not check the registration of
the VLAN. As MPLS-TP does not have a clps transport entity, there are no
fitlering rules to check within the MPLS-TP transport entities MS-PW, LSP
and Section. As such the LT OAM fucntion is not applicable for MPLS-TP.

[mv] MPLS-TP may want to have an OAM function that can check the
registration of a MS-PW or LSP transport entity in the swtiching nodes; for
Ethernet such OAM function would then check the registration of a VLAN
transport entity.

[mv] Q.5/13 has performed a first analysis of how to provide such transport
entity registration check OAM function in its Dec. 2006 meeting. The result
of this analysis is documented in WD28R1
http://ties.itu.int/u/tsg13/sg13/xchange/wp4/q5/0612_Sophia/WDs/wd28r1_multi
ple-loopbacks.doc.

Regards,
Maarten

Informational
-------------------
6. The MEP and MIP definition is not correct. If you look at 802.1ag you
will realize that:

   MEP    MA End Point

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