Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map

"Shahram Davari" <davari@broadcom.com> Tue, 04 December 2012 09:22 UTC

Return-Path: <davari@broadcom.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B2821F8659 for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 01:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.269
X-Spam-Level:
X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX2E6srVE2uY for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 01:22:29 -0800 (PST)
Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3421F85E6 for <mpls@ietf.org>; Tue, 4 Dec 2012 01:22:29 -0800 (PST)
Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 01:17:53 -0800
X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF
Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 01:22:18 -0800
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 01:21:57 -0800
From: Shahram Davari <davari@broadcom.com>
To: Rolf Winter <Rolf.Winter@neclab.eu>
Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
Thread-Index: AQHN0gDOGLzGkGQffUCu8eKg5ppt/Q==
Date: Tue, 04 Dec 2012 09:21:57 +0000
Message-ID: <1C7E7722-1249-44A1-AF38-FD6CA490718D@broadcom.com>
References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <F0E40950-2607-4AB5-BB17-88EFC41C1603@yahoo.com> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <CAGEmCZyDCBV-vdA96Amnx-08U-Xq_6t+mnF34k8o_8tX+4z2VQ@mail.gmail.c> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <B5CDD7D1-CBD7-4E74-ADE6-0DEBE26E3757@broadcom.com> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5003751U50bd483f@hitachi.com> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.broadcom.com>, <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
MIME-Version: 1.0
X-WSS-ID: 7CA3604A39W4985624-01-01
Content-Type: multipart/alternative; boundary="_000_1C7E7722124944A1AF38FD6CA490718Dbroadcomcom_"
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 09:22:33 -0000

Rolf,

The job of OAM is to diagnose issues in the data plane. This means OAM has to take the same path as Data. Therefore on a P2MP LSP, OAM must be multicasted, similar to data. You can't just send to one MEP or MIP.


Here is what RFC6371 says:


P2MP Considerations
All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves. As a consequence:

 o To send an OAM packet to all leaves, the source MEP can send a single OAM packet that will be delivered by the forwarding plane to all the leaves and processed by all the leaves. Hence, a single OAM packet can simultaneously instrument all the MEs in a P2MP MEG.

 o To send an OAM packet to a single leaf, the source MEP sends a single OAM packet that will be delivered by the forwarding plane to all the leaves but contains sufficient information to identify a target leaf, and therefore is processed only by the target leaf and can be silently discarded by the other leaves.

So although you can send a targeted OAM message to only one MEP or MIP, but the same message is going to be received by all MEPs or MIPs (with same TTL distance). The others just drop it.

So in the MIP example provided the ingress port of a router can't decide to which selective egress port it has to send the OAM packet to.  The only decision it can make is that an OAM message is or is not for itself (the in-MEP). Each egress port also decide individually whether the OAM is for itself or not, and if not just drops the packet.

So for sure the in-MEP doesn't need to look at MEPID to decide whether to terminate and send the OAM packet to CPU or forward normally. A single bit is enough for making such decision. Regarding out-MIPs, there are 2 options:

1) send OAM packet received with TTL expiry to CPU and let CPU look at MEPID and if not correct drop it

2) let the HW to look at MEPID and if correct, send the packet to CPU, else drop it.

I agree the 2nd option is more efficient, but is not practical, since locating arbitrarily located TLVs in various different OAM packet types such as BFD, LSP-Ping, etc is not practical.

Thx
Shahram






Regards,
Shahram


On Dec 4, 2012, at 12:34 AM, "Rolf Winter" <Rolf.Winter@neclab.eu<mailto:Rolf.Winter@neclab.eu>> wrote:

Shahram,

what if it is configured and you only want to talk to one out of all the out-MIPs. I guess we can all craft examples where we can make our point. A single bit simply does not guarantee you that the local CPU does not have to look at the OAM frame to finally discard it.

Best,

Rolf

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


-----Original Message-----
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Dienstag, 4. Dezember 2012 01:53
To: hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>
Cc: Rolf Winter; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-
tp-mip-mep-map

Hi Hideki,

I think you need to look at my p-code. F a MIP is not configured in the
Egress port, then that egress port won't sent the OAM packet to its
processor and drops it. So there is no issue with my proposed method.

Thx
Shahram

-----Original Message-----
From: hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com> [mailto:hideki.endo.es@hitachi.com]
Sent: Monday, December 03, 2012 4:48 PM
To: Shahram Davari
Cc: Rolf.Winter@neclab.eu<mailto:Rolf.Winter@neclab.eu>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-
mip-mep-map

Hi Shahram,

First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a
MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests
Here, CV means On-demand CV. You may misunderstand as Proactive CV.

Second, you wrote;
"The issue is that each CPU/processor has limited resources.
By sending all OAM MIP packets to both processor you are  losing 1/2
of the capacity of each processor. "
It depends on implementations,
and this issue could NOT be resolved by even your solution that uses
ACH header to indicate in/out-MIP.
Let's consider P2MP case as you pointed out.
All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs.
This means that the OAM processor at port D loses its capacity.
If we consider the larger number of ports in the LSR which has 100
ports, for example, All OAM MIP packets for out-MIPs port(B, C) are
sent to all out-MIPs.
This means that the OAM processors at the other 98 ports lose those
capacities.
Even if your solution using ACH header is applied, it can reduce OAM
packets only for in-MIP, which means only 1/101 effectiveness in the
case of P2MP for 100 ports.

Thanks,
Hideki Endo


Rolf,

For clarity it is better to use an example. Assume that an LSR has 4
ports (A, B, C, D). Now assume that it receives packets  on a unicast
LSP-X from port A and forwards them to port B.  there can only be 3
configurations:

1) MIP on port A (In-MIP), or
2) MIP on port B (out-MIP), or
3) MEIP on Port A and B

A single OAM packet can be terminated and processed only by one of
these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port
B). In your example, you are saying send a copy of the P to the
CPU/Processor on Port A, and send a copy also to CPU/Processor on Port
B. Port A CPU will drop the packet since the MIP-ID is not A.  The
issue is that each CPU/processor has limited resources.  By sending all
OAM MIP packets to both processor you are losing 1/2 of the capacity of
each processor.  The practical solution is to have a simple indicator
in the packet header that this OAM packet is meant for Out-MIP. Then
port A just switches the OAM packet to Port B, and Port B terminates
and sends it to its CPU/processor.

Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the
chip from Port A and is sent to ports B, C, D.  Also assume that there
is In-MIP on port A and out-MIPs of ports B, C (not D).  Now assume a
Multicast OAM packet is  meant for out-MIPs (B, C). In such case the
OAM packet should not be sent to port A CPU/Processor. It is therefore
multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU.
Port D drops the OAM packets and does not send it to its CPU, since
there is no MIP configured for that MPLS label.

So the Pseudo-code is like this:

Ingress Port:

If packet is OAM and TTL=1
   If MIP is enabled
       If packet indicates In-MIP
           Send to local CPU
       Else
           Forward to egress port
       End
   Else
       Forward normally
   End
Else

Egress Port:

If packet is OAM and TTL=1
   If MIP is enabled
       If packet indicates In-MIP
           Drop  packet
       Else If packet indicates Out-MIP
           Send to local CPU
       End
   Else
       Drop packet
   End
End


Using this example could you please describe your reasoning for not
requiring HW to identify In-MEP vs out-MIPs?

Thanks
Shahram

-----Original Message-----
From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
Sent: Monday, December 03, 2012 12:10 PM
To: Shahram Davari
Cc: Pablo Frank; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: [mpls] working group last call on
draft-ietf-mpls-tp-mip-mep-map

But the MIP that is addressed needs to be able to handle this _plus_
take an appropriate action and in the P2MP case this will always be the
case since there are 2 or more out MIPs.

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


-----Original Message-----
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Montag, 3. Dezember 2012 16:27
To: Rolf Winter
Cc: Pablo Frank; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip- mep-map

Hi Rolf,

Your HW guys are correct as long as the amount of data sent to the
in- MIP processor is not much. But from your previous email to Loa I
see that you want to also terminate CV at MIPs. CVs are fast and
high
bandwidth and blindly dumping them on a CPU or OAM processor  that
may not be expecting them is like DoS attack.



Regards,
Shahram


On Dec 3, 2012, at 5:53 AM, "Rolf Winter" <Rolf.Winter@neclab.eu<mailto:Rolf.Winter@neclab.eu>>
wrote:

Hi,

sorry for the belated response. I checked with some of our HW
people.
Here's the gist of their response:

Of course they wouldn't like parsing TLVs but we established that
fact already. Their answer to the problem is slightly different
though.
A TTL-expired OAM frame can simply be copied and forwarded to the
out- MIPs where, if the frame is not intended for them, it can
safely
be dropped. In the P2MP case e.g. this needs to be done anyway, i.e.
the implementation must behave in this exact way in either case. So
there is at least one way to implement this at line rate without
going back and changing a bunch of RFCs.

Best,

Rolf

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


-----Original Message-----
From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On
Behalf Of Shahram Davari
Sent: Mittwoch, 28. November 2012 18:46
To: Pablo Frank
Cc: mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip- mep-map

Pablo,



That was exactly my point. Let's use a flag to indicate in-MIP or
out- MIP and then the offline processor can do MEPID lookup to
determine whether this is a legitimate OAM packet or not.



Thx
Shahram



From: Pablo Frank [mailto:pabloisnot@gmail.com]
Sent: Wednesday, November 28, 2012 8:22 AM
To: Shahram Davari
Cc: mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip- mep-map



I think Shahram raises a very legitimate concern about how
expensive this could be to implement in hardware.



As I understand it, the logic proposed by this draft is as
follows:



At the ingress blade:



IF TTL-expired && GAL-is-present && GACh-type-is-X THEN

 Parse MIP-ID TLV

 Lookup MIP-ID

 IF MIP-is-egress, THEN

    forward normally (but note we must intercept it again on
egress)

 ELSE

    punt to OAM processor



At the egress blade:



IF TTL-expired && GAL-is-present && GACh-type-is-X THEN

 Parse MIP-ID TLV

 Lookup MIP-ID

 IF MIP-is-egress, THEN

    punt to OAM processor

 ELSE

    drop



Note all this has to be done in the fast-path now at full line
rate (and hardware guys hate TLVs).  Before, the only thing the
fast-path had to do was look for TTL-expiry.



The only reason that ACH reserved bit was rejected (in Appendix
A.4 of
-03 version of doc) was because it also required a MIP-ID lookup.
But I don't see anything wrong with combining both mechanisms.
Ideally, hardware could rely on the reserved bit to do the
initial
filtering at full line-rate and then a presumably much more
cost-efficient OAM hardware block could perform the MIP-ID lookup.
Instead of the complex logic above, the fast path gets a simple
modification to TTL handling and the OAM block does the heavy
lifting of dealing with ACH TLVs, etc.



This seems like a case where practicality should trump elegance.



regards,

Pablo



On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari
<davari@broadcom.com<mailto:davari@broadcom.com>>
wrote:



Rolf,

I am sure you know that TLVs are not Hardware friendly. And
I
think you agree with me that this draft requires deep parsing of
all packets at line rate to get to the MIPID TLV.

I still think the MIPID TLV is required to decide whether an
OAM
packet ended up  at the right MIP. But may be a simpler solution
could be augmented to decide between In-MIP and Out-MIP. For
example how about using one of the reserved bits in the ACH
header.  This
can
easily be done in hardware with minimum complexity.

Regards,
Shahram



-----Original Message-----
From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org]
On
Behalf Of Rolf Winter
Sent: Wednesday, November 21, 2012 12:13 PM
To: S. Davari; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls- tp-mip-mep-map

Hi,

Hi Adrian,

You are right and I should have sent these types of
comments
before
last call. I completely understand the procedure.

One thing I didn't understand in your response is that you
said
in-MIP
requires to do the MEPID lookup at line rate anyway. Why is
that?

My understanding is that before this draft,  the process
would have
been for the ingress to look at TTL and if it is expired
then send the
packet to OAM processor.

Yes (and no). While I assume likely MIP functionality will
be
implemented on the ingress, the related RFCs are vague about the
actual placement of the MIP function. See e.g. the OAM Framework
(RFC
6371) "per-node MIPs (i.e., a single MIP per node in an
unspecified location within the node)".

Also, I think "before this draft" is not quite accurate in
that is suggests there is no per-interface MIP addressing
possible
as of
now.
Take RFC 6426. In practice this is where part of the problem lies.
We
cannot really go back and change all this. There are other
constraints.
E.g. we have a requirement to address a single out-MIP out of a
set of out-MIPs on a P2MP branch point.  So this was part of the
constraints we worked with.


The MEPID that you suggest in this draft is very useful for
filtering
out leaked OAM frames from upstream. But lets leave lookup
of the MEPID
to the OAM processing module (at slower rate) and add an
indicator to
the OAM packet to indicate whether it should be taken out
of
the data
path in the Ingress or egress.

So can I suggest adding the following text to the draft:

" In addition to the MEPID, which is used to ultimately
accept or
filter out received OAM packets, OAM packets  should have a
simple
indicator that identifies whether the OAM packet belongs to
in-MIP or
Out-MIP".

We also have the question on where to retrofit those bits. I
assume a TLV wouldn't work for the exact reasons you do not like
to have to do a second lookup, since it would require some
parsing. All these constraints and the ones outlined in the
document led to where we are. In a sense this is a non-spec since
it rather rules out a number of things that seem like a good idea
at first but then have a catch of some sort.

Best,

Rolf




Regards,
Shahram


On Nov 21, 2012, at 1:16 AM, "Adrian Farrel"
<adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
wrote:

<co-author mode>

Hi Shahram,

I am worried about the precedent of a comment like this
during
WG
last call.
While comments that improve the document or point out
fundamental
flaws are welcome whenever they arrive, points with the
flavour "I
wouldn't have done it like this" that arrive this late in
the process
don't feel very constructive.
But I will leave the chair to worry about process and try
to address
the technical points...

Identifying whether to terminate an OAM packet and
process
it
in In-
MIP vs.
Out-
MIP requires line rate lookup, otherwise the OAM packet
will not
take
the same path as data packets.  Therefore any MIP
identifier that is
proposed in this
draft
requires one extra lookup and therefore adds
significantly
to
cost.

If I am not wrong, this is a feature of an out-MIP. If you
decide to
implement out-MIPs, and if you want the OAM to follow
exactly the
same
path as the data, then it is a requirement that the out
interface
inspects the packets (at line
rate) to determine whether they are OAM and targeted at
the
interface.

We cannot change that aspect. All we can do is aim to make
the
lookup
as easy as possible.

Perhaps a
similar method to Ethernet MDL/MEL (Maintenance Domain
Level) may be
used that requires only 3 bits and achieves the same
result.

Perhaps it could.
But before going there, why is the lookup in the current
version of
the I-D arduous?

Presumably you do not propose making any change to the way
In-MIPs
are
currently identified, so the lookups being done at line
rate today on
the incoming interfaces will not be changed. If you are
proposing
such
a change, then the discussion is outside the scope of this
I- D and
becomes a much wider question for the working group.

This leaves me with the trade-off of enabling a *simpler*
lookup on
the outgoing interfaces versus doing identical lookups on
both
interfaces. My assumption was that if the incoming
interface can do
the lookup at line rate, it is not hard to perform the
same
lookup on
the outgoing interface. Furthermore, there is a reduction
in
complexity by having fewer things to look up.

Another possibility is that the full lookup could be done
on the
incoming interface and the packet marked for easy
interception
on the
outgoing interface.
The concern with this approach is that the packet would no
longer be
being forwarded exactly as data because it would be being
modified in
flight.
Furthermore, in the case of P2MP, it is not enough to flag
the
packet
as a local Out-MIP and further identifier-based lookup is
needed.

Some of these issues were raised and discussed as the I-D
progressed,
and some of the alternative solutions were tracked with
their pros
and
cons in Appendix A of the I-D (look at revision -03).

Thanks,
Adrian
-----Original Message-----
From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-
bounces@ietf.org<mailto:bounces@ietf.org>]
On
Behalf
Of Adrian Farrel
Sent: Monday, November 19, 2012 8:45 AM
To: 't.petch'; 'Loa Andersson'; mpls@ietf.org<mailto:mpls@ietf.org>
Cc: mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>
<mailto:mpls-chairs@tools.ietf.org> ;
draft-ietf-mpls-tp-mip-
mep-map@tools.ietf.org<mailto:mep-map@tools.ietf.org>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip-mep-map

Yeah, it's a boring draft. Did you expect me to co-author
anything
else?

The point was that when I started the I-D lots of people
were
saying
"it's complex" and "it can't be done" and "it won't be
backward
compatible".

So the I-D says "here it is"

A (sorry not to offer you excitement)

-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]
Sent: 19 November 2012 12:38
To: Loa Andersson; mpls@ietf.org<mailto:mpls@ietf.org>
Cc: mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>
<mailto:mpls-chairs@tools.ietf.org> ; MPLS-TP ad
hoc
team;
draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>
Subject: Re: [mpls] working group last call on
draft-ietf-mpls-tp-mip-mep-map

After getting to section 6 and its features
(requirements!), I find
myself underwhelmed; is that it?  Well, I suppose so, it
is
Informational and not Standards Track.

Meanwhile, I suggest some editorial issues.

Title
Handling MPLS-TP OAM Packets Targeted at Internal MIPs
[Handling
MPLS-TP OAM Packets Targeted at Interface MIPs seems a
more
informative statement unless and until you get to the
definition of
Internal in s3; and s6, which is the crux of the
document
says The
preferred solution to per-interface MIP message handling
is
presented in this section]

s1
two (or more) MIPs per node on both sides of the
forwarding engine.
[two on both sides sounds like four in total to me;
suggest 'one on
each side of the forwarding engine']

s4
o  CV between a MEP and a MIP
[expand CV on first use]

s5
In-band OAM messages are sent using the G-ACh [RFC5586]
for MPLS-TP
LSPs and MPLS-TP PWs, respectively.
['respectively' suggests to me that there should be two
precedents,
not just RFC5586; the second paragraph specifies RFC5586
for
LSPs,
RFC6423/RFC4385 for PWs, in which case, strike this
sentence
as
redundant]

s6
The appendix of this document contains a
few solutions that the authors have discarded which
have
been
left in
the document for informational purposes.
[not any more they haven't!]

The node itself is addresses
[The node itself is addressed]

The identification information indside [The
identification
information inside ]

MIP identifiers are not know
[MIP identifiers are not known]

reserved MIP address
[reserved MIP addressses or a reserved MIP address]

Tom Petch


----- Original Message -----
From: "Loa Andersson" <loa@pi.nu<mailto:loa@pi.nu>>
To: <mpls@ietf.org<mailto:mpls@ietf.org>>
Cc: <mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>>; <mpls-
chairs@tools.ietf.org<mailto:chairs@tools.ietf.org>>;
"MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int<mailto:ahmpls-tp@lists.itu.int>>;
<draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>>
Sent: Wednesday, November 14, 2012 3:16 PM

Working Group,

This is to start a 2 week working group last call on
draft-ietf-mpls-tp-mip-mep-map.

Please send your comments to the mpls working group
mailing
list
(mpls@ietf.org<mailto:mpls@ietf.org>).

Please send both technical comments, and if you are
happy with the
document as is also indications of support.

This working group last call will end on November 28.

/Loa
for the wg co-chairs


_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls

NEC Europe Limited | Registered Office: NEC House, 1
Victoria
Road, London W3 6BL | Registered in England 2832014
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls



  _______________________________________________
  mpls mailing list
  mpls@ietf.org<mailto:mpls@ietf.org>
  https://www.ietf.org/mailman/listinfo/mpls





_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls