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

["S. Davari" <[e-mail]>]

Hi Rolf,

For in-MIP a single bit is enough. However for out-MIP the CPU has to drop the unwanted OAM. Not efficient but the system still works. Remember this happens only in a corner case of p2mp MPLS with multiple out-MIP on the same router, and when only root wants to talk to one of the leaves. 

That's why I am suggesting to have a single bit in addition to the MEPID.

Regards,
Shahram


On Dec 4, 2012, at 12:33 AM, Rolf Winter <[e-mail]> 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:[e-mail]]
>> Sent: Dienstag, 4. Dezember 2012 01:53
>> To: [e-mail]
>> Cc: Rolf Winter; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]]
>> Sent: Monday, December 03, 2012 4:48 PM
>> To: Shahram Davari
>> Cc: [e-mail]; [e-mail]
>> 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:[e-mail]]
>>> Sent: Monday, December 03, 2012 12:10 PM
>>> To: Shahram Davari
>>> Cc: Pablo Frank; [e-mail]
>>> 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:[e-mail]]
>>>> Sent: Montag, 3. Dezember 2012 16:27
>>>> To: Rolf Winter
>>>> Cc: Pablo Frank; [e-mail]
>>>> 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" <[e-mail]>
>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf Of Shahram Davari
>>>>>> Sent: Mittwoch, 28. November 2012 18:46
>>>>>> To: Pablo Frank
>>>>>> Cc: [e-mail]
>>>>>> 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:[e-mail]]
>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM
>>>>>> To: Shahram Davari
>>>>>> Cc: [e-mail]
>>>>>> 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
>>>>>> <[e-mail]>
>>>>>> 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: [e-mail] [mailto:[e-mail]]
>> On
>>>>>> Behalf Of Rolf Winter
>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM
>>>>>>> To: S. Davari; [e-mail]
>>>>>>> Cc: [e-mail]
>>>>>>> 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"
>>>>>> <[e-mail]>
>>>>>>>> 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: [e-mail] [mailto:mpls-
>> [e-mail]]
>>>> On
>>>>>> Behalf
>>>>>>>>>> Of Adrian Farrel
>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM
>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; [e-mail]
>>>>>>>>>> Cc: [e-mail]; [e-mail]
>>>>>> <mailto:[e-mail]> ;
>>>>>>>>> draft-ietf-mpls-tp-mip-
>>>>>>>>>> [e-mail]
>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>> Sent: 19 November 2012 12:38
>>>>>>>>>>> To: Loa Andersson; [e-mail]
>>>>>>>>>>> Cc: [e-mail]; [e-mail]
>>>>>> <mailto:[e-mail]> ; MPLS-TP ad
>>>>>>>>>>> hoc
>>>>>>>>> team;
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> 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" <[e-mail]>
>>>>>>>>>>> To: <[e-mail]>
>>>>>>>>>>> Cc: <[e-mail]>; <mpls-
>>>>>> [e-mail]>;
>>>>>>>>>>> "MPLS-TP ad hoc team" <[e-mail]>;
>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>> 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
>>>>>>>>>>>> ([e-mail]).
>>>>>>>>>>>> 
>>>>>>>>>>>> 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
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> mpls mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>> _______________________________________________
>>>>>>>> mpls mailing list
>>>>>>>> [e-mail]
>>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>> 
>>>>>>   _______________________________________________
>>>>>>   mpls mailing list
>>>>>>   [e-mail]
>>>>>>   https://www.ietf.org/mailman/listinfo/mpls
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls