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

From: "Shahram Davari" <[email-masked]>
Date: Wed, 6 Mar 2013 19:30:04 +0000

My Comments are addressed and I support this draft to be published as Informational  RFC.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, February 26, 2013 3:02 AM
To: [email-masked]
Cc: <[email-masked]>; [email-masked]; [email-masked]
Subject: [mpls] 2nd working group last call on draft-ietf-mpls-tp-mip-mep-map

Working Group,

draft-ietf-mpls-tp-mip-mep-map-05.txt has been updated after a
previous last call, due to the nature a and extent of the updates
we have chosen to start a 2nd wg last call.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-mip-mep-map-05

Please send your comments, including approval of the documents and
the updates to the mpls working group list ([email-masked])

This working group last call ends March 13, 2013.

/Loa
for the MPLS working group co-chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consult)        phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Pablo Frank <[email-masked]>
Date: Tue, 12 Mar 2013 11:16:25 -0400

I'm still a little wary of the wording on pg. 9, 4th bullet.  Currently,
the draft suggests that packet inspection needs to be minimized.  My
concern with the original solution proposal was that it required a new
line-rate *lookup*.  There was a secondary concern around parsing TLVs
which this point *does* appear to address, but minimizing 'inspection' does
not seem to preclude new lookups.  One of the nice things about MPLS OAM as
it's defined today is that relatively easy to get off-the-shelf forwarding
hardware to trap / redirect OAM frames to a separate OAM block that could
perform the OAM validation and lookups.  This is because encountering a
GACh or a TTL expiry as part of regular MPLS handling unambiguously
terminates the frame (and note that it doesn't require an OAM-specific
lookup in the main-line forwarding hardware).  I'd like this draft to set
avoiding new OAM-specific lookups as a design objective, or you risk
precluding a whole class of (cheap, high volume) hardware from being able
to do this function.

regards,
Pablo

On Wed, Mar 6, 2013 at 2:30 PM, Shahram Davari <[email-masked]> wrote:

> Cc: <[email-masked]>; [email-masked];
> [email-masked]

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 02:32:26 +0900

Hi Pablo,

Thank you for your comments.

If you don't want any change for your equipments,
you can select per-node MIP option.
Otherwise, it is needed to change something.
Even if you change something in your cheap and high volume hardware,
the cost would be very low in the case of minimum change as our draft says.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 12 Mar 2013 18:01:55 +0000

Hi,

Although I mentioned I am Ok with the draft to be advanced to RFC, but after reviewing it in more details it appears that the draft, in spite of its name, does talk about UP-MEP at all and only talks about UP-MIP, while the figures show UP-MEPs for LSPs.  Even if the scope of the draft is UP-MIP, considering that there can't be a MIP without a MEP,  the draft should have some wording regarding UP-MEPs and their applicability to LSPs and PWs. I would also argue that LSPs can't have UP-MEPs, since PWs from many ingress ports can enter an LSP  and therefore the LSP can't start on the ingress interface.

A quick fix at this point is to mention UP-MEP is out of scope and change the figures to only show Down-MEPs. A better fix is to elaborate on UP-MEP and its applicability and placement, etc.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Wednesday, March 06, 2013 11:30 AM
To: Loa Andersson; [email-masked]
Cc: <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd working group last call on draft-ietf-mpls-tp-mip-mep-map

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, February 26, 2013 3:02 AM
To: [email-masked]
Cc: <[email-masked]>; [email-masked]; [email-masked]
Subject: [mpls] 2nd working group last call on draft-ietf-mpls-tp-mip-mep-map

Working Group,

/Loa

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 03:19:30 +0900

Hi Shahram,

Just one comment.

>I would also argue that LSPs can't have UP-MEPs, since PWs from many ingress ports can enter an LSP  and therefore the LSP can't start on the ingress interface.

I think this depends on implementations.
Any RFC don't restrict to DOWN-MEPs in an LSP.

Anyway, MEP mechanism is out of scope in this draft as you said.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 12 Mar 2013 18:30:28 +0000

Hideki,

So far no RFC or draft has talked about Down or UP MEP for LSPs. But if you think about it logically LSPs can't have UP-MEP because LSP can carry many PWs and each PW may enter the LSP from a different port/interface.  PWs can have UP-MEP but only for P2P services (VPWS), otherwise they can't have UP-MEP either (same as LSP).

My suggestion is to correct figures and change UP-MEPs to Down-MEPs for LSPs. Also to mention UP-MEP is out of scope.

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Mar 2013 18:56:09 +0000

Dear All,
What would be the most appropriate subject to continue this discussion? I'll give it a try, please feel free to change it.

I think that there's nothing that can preclude from supporting UP MEP on MPLS-TP LSP, according to UP MEP definition of RFC 6371, even when multpiple PWs mapped to that LSP. Same, I think, is the true for  p2mp PW. Note that service, VPWS, is not part of MPLS-TP architecture.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hideki,

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

>draft-ietf-mpls-tp-mip-mep-map-05.txt has been updated after a previous
>last call, due to the nature a and extent of the updates we have chosen
>to start a 2nd wg last call.
>
>Please send your comments, including approval of the documents and the
>updates to the mpls working group list ([email-masked])
>

---

From: Rolf Winter <[email-masked]>
Date: Tue, 12 Mar 2013 19:51:35 +0000

Hi,

the wording is not as explicit as you suggest but for a requirement I personally feel that is alright since we do not yet know how the solution looks like. In other words, once a solution is proposed it is up to the WG to decide whether the overhead of that particular solution is acceptable or not. 

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pablo Frank
> Sent: Dienstag, 12. März 2013 16:16
> To: Shahram Davari
> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-tp-mip-
> [email-masked]; <[email-masked]>
> which this point *does* appear to address, but minimizing 'inspection'
> does not seem to preclude new lookups.  One of the nice things about
> MPLS OAM as it's defined today is that relatively easy to get off-the-
> shelf forwarding hardware to trap / redirect OAM frames to a separate
> OAM block that could perform the OAM validation and lookups.  This is
> because encountering a GACh or a TTL expiry as part of regular MPLS
> handling unambiguously terminates the frame (and note that it doesn't
> require an OAM-specific lookup in the main-line forwarding hardware).
> I'd like this draft to set avoiding new OAM-specific lookups as a
> design objective, or you risk precluding a whole class of (cheap, high
> volume) hardware from being able to do this function.
> 
> regards,
> Pablo
> 
> 
> <tel:%2B46%20739%2081%2021%2064>

---

From: "Zhenlong Cui" <[email-masked]>
Date: Thu, 14 Mar 2013 03:44:39 +0900

Hi Shahram,

Some, at least in case of ring topology, the LSP UP-MEP is a necessity.

As you know, a intermediate node on a ring network have to supports Swap & POP processing.
There are some OAM models should be taken into consideration for intermediate node, as follows:

(1) Set Down-MEP only
 If we support the down-mep only and set down-mep at Down I/F(swap point), OAM will not be transmitted to downstream node.

(2) Set Down-MIP and UP-MIP
 For support the LSP Protection at the intermediate node, the MEP must be set at the POP Point.
 
 Note:
  MPLS-TP recovery in a ring must protect unidirectional P2MP transport paths as specified in RFC 5654.

(3) Set Down-MIP and UP-MEP
 This model can solve above model's issues.

Best regards,
zhenlong

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, March 13, 2013 3:56 AM
To: Shahram Davari; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Dear All,
 
I think that there's nothing that can preclude from supporting UP MEP on MPLS-TP LSP, according to UP MEP definition of RFC 6371,
even when multpiple PWs mapped to that LSP. Same, I think, is the true for  p2mp PW. Note that service, VPWS, is not part of MPLS-TP
architecture.
 
        Regards,
                Greg
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
 
Hideki,
 
So far no RFC or draft has talked about Down or UP MEP for LSPs. But if you think about it logically LSPs can't have UP-MEP because
LSP can carry many PWs and each PW may enter the LSP from a different port/interface.  PWs can have UP-MEP but only for P2P services
(VPWS), otherwise they can't have UP-MEP either (same as LSP).

Thx
SD
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
 
Hi Shahram,
 
Just one comment.

 
 
Thanks,
Hideki Endo
 
>Hi,
>
>Although I mentioned I am Ok with the draft to be advanced to RFC, but after reviewing it in more details it appears that the
draft, in spite of its name, does talk about UP-MEP at all and only talks about UP-MIP, while the figures show UP-MEPs for LSPs. 
Even if the scope of the draft is UP-MIP, considering that there can't be a MIP without a MEP,  the draft should have some wording
regarding UP-MEPs and their applicability to LSPs and PWs. I would also argue that LSPs can't have UP-MEPs, since PWs from many
ingress ports can enter an LSP  and therefore the LSP can't start on the ingress interface.
>
>A quick fix at this point is to mention UP-MEP is out of scope and change the figures to only show Down-MEPs. A better fix is to
elaborate on UP-MEP and its applicability and placement, etc.
>Shahram Davari
>Loa Andersson

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 18:53:12 +0000

Hi,

I don't really understand what you are trying to say. Can you provide an example.

Thx
SD

-----Original Message-----
From: Zhenlong Cui [mailto:[email-masked]] 
Sent: Wednesday, March 13, 2013 11:45 AM
To: 'Gregory Mirsky'; Shahram Davari; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Hi Shahram,

(1) Set Down-MEP only

 Note:

Best regards,
zhenlong

Dear All,

        Regards,
                Greg
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
 
Hideki,

 
Thx
SD
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
 
Hi Shahram,
 
Just one comment.

 
 
Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 18:59:18 +0000

Greg,

RFC6371 is very high level and does not define whether UP MEP applies to LSP or PW.  Assume there are 2 ingress interfaces A & B. Each interface maps Ethernet traffic to its own PW (PW-A and PW-B). Now assume both these PWs go inside the same LSP that exists Interface C. Now please explain if we were to have an UP-MEP for LSP then on which interface would that LSP UP-MEP reside? Interface A? B? C?

This simple example shows you can't have an LSP UP-MEP.

Thx
SD

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:56 AM
To: Shahram Davari; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Dear All,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hideki,

Thx
SD

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
>Shahram Davari
>To: Loa Andersson; [email-masked]<mailto:[email-masked]>
>Cc: <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
>Loa Andersson
>To: [email-masked]<mailto:[email-masked]>
>Cc: <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>updates to the mpls working group list ([email-masked]<mailto:[email-masked]>)
>
>Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
>Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Mar 2013 19:41:40 +0000

Hi Shahram,
UP MEP, whether as defined by RFC 6371 or as defined elsewhere, e.g. IEEE 802.1ag, is not required to be co-located with an ingress to monitored service, e.g. attachement circuit, but with logical interface that represents monitored service. Location of UP MEP is undefined as long as it complies with where is sends to and receives from OAM packets/frames. In case of MPLS this element if MPLS forwarding function, in case of Ethernet - Bridge Relay Entity. For MPLS, as long as OAM packets sent to forwarding and get proper encapsulation, IMHO, we have ourselves an UP MEP. How packet being bounced within a node to get such treatment, I think, is implementation specific.

    Regards,
        Greg

________________________________
From: Shahram Davari [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 11:59 AM
To: Gregory Mirsky; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Greg,

Thx
SD

Dear All,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hideki,

Thx
SD

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 19:55:21 +0000

Greg,

We have a fundamental difference of opinion.  I have been involved in the OAM for over a decade now and one of the fundamental architectural requirements is that OAM packets MUST follow the data packets in the network and inside a switch/router up to the observation point (MEP). So it is not acceptable for data packets to be on Interface A and for MEP to be on Interface B.

In the example I gave, can you please tell me how you can do Loss Measurement for the LSP with UP-MEP? How do you increment the LSP UP-MEP receive LM counters for packets received from PW-A and PW-B? and where is the LSP-UP-MEP located?

Thx
Shahram

Sent: Wednesday, March 13, 2013 12:42 PM

Hi Shahram,

    Regards,
        Greg

To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>

Thx
SD

To: Shahram Davari; [email-masked]<mailto:[email-masked]>

Dear All,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hideki,

Thx
SD

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Mar 2013 20:06:15 +0000

Hi Shahram,
I believe that MPLS-TP LM is what is called Synthetic Loss Measurement and does not require reporting in-profile counters. If my understanding is correct, then I don't see how location of UP MEP in relation to PW A and PW B is important. Besides, could you refer me to definition of in-profile and out-ot-profile in regard to MPLS-TP. Much obliged.
As for your challenge I do have solution but, I believe, it is HW specific. Sorry if you can not do that.

    Regards,
        Greg

Sent: Wednesday, March 13, 2013 12:55 PM

Greg,

Thx
Shahram

Hi Shahram,

    Regards,
        Greg

Thx
SD

Dear All,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hideki,

Thx
SD

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

---

From: "Zhenlong Cui" <[email-masked]>
Date: Thu, 14 Mar 2013 05:06:32 +0900

Hi Shahram,

   Give you an example....

   OAM must operate on MPLS-TP nodes that are branch points on point-to-
   multipoint (P2MP) trees include ring topology. That means that the branch
   points must be possible to drop & continue the received OAM frame.
   
   If the Down-MEP is configured at ingress i/f(LSP Terminal Point) as shown 
   below figure, then the received OAM frame will be blocked by ingress i/f 
   and can't transmit to downstream link.
   
   I think it is a problem.

                         --------------------------
                        |                     -----|
                        |                    | N/A |
                        |                 ->-|     |->-------------LSP (Downstream link)
                        |                |   | Out |
                        |                |   | i/f |
                        |                |    -----|
                        |-----           |    -----|
                        | MEP |    ----  |   | N/A |
                        |     |   |    |-    |     |
              LSP----->-| In  |->-| FW |--->-| Out |->----UNI
                        | i/f |   |    |-    | i/f |
                        |-----     ----  |    -----|
                        |                |    -----|
                        |                |   | N/A |
                        |                |   |     |
                        |                 ->-| Out |->----UNI
                        |                    | i/f |
                        |                     -----|
                         --------------------------

Best regards,
Zhenlong

> Sent: Thursday, March 14, 2013 3:53 AM
> To: Zhenlong Cui; 'Gregory Mirsky'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> >I would also argue that LSPs can't have UP-MEPs, since PWs from many ingress ports can enter an LSP  and therefore the
> LSP can't
> start on the ingress interface.
>

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 21:20:55 +0000

Greg,

First of all MPLS-TP LM can use direct Loss measurement of RFC6374.

Secondly I am not asking on what is your implementation. I am asking logically how do you do LM for LSP UPMEP. You have to let the data packets go through forwarding and queuing and be actually delivered to the egress interface before you can increment receive LM counter. Just examining the forwarding result is not enough since for example the link between egress line card and the fabric can be broken or have errors.

Regards,
Shahram

On Mar 13, 2013, at 1:06 PM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shahram,

    Regards,
        Greg

Greg,

Thx
Shahram

Hi Shahram,

    Regards,
        Greg

This simple example shows you can’t have an LSP UP-MEP.

Thx
SD

Dear All,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hideki,

Thx
SD

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map

Hi Shahram,

Just one comment.

Thanks,
Hideki Endo

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Mar 2013 22:12:32 +0000

Hi Shahram,
as indicated before, Synthetic LM is viable option and will work just fine from UP MEP. Would you agree?

    Regards,
        Greg

________________________________
From: Shahram Davari [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 2:21 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Greg,

Regards,
Shahram

Hi Shahram,

    Regards,
        Greg

Greg,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 07:30:50 +0900

Sharam,

Very simple question.

>Assume there are 2 ingress interfaces A & B. Each interface maps Ethernet traffic
>to its own PW (PW-A and PW-B). Now assume both these PWs go inside the same LSP that exists Interface C. 
Why is this assumption mandatory?

"Assume there are 1 ingress interfaces A. Two VLAN flows in the interface A are mapped
 to different PWs (PW-A and PW-B). Now assume both these PWs go inside the same LSP."
In this case, UP-MEP of the LSP can be at interface A, right?

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 22:30:40 +0000

Hi Greg,

Correct, but we can't define a MEP that can only support a subset of OAM specially the less desirable ones. Besides Synthetic loss is not accurate and as far as I know, not many users are interested in Synthetic loss.

Thx
SD

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 3:13 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Hi Shahram,

    Regards,
        Greg

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Regards,
Shahram

    Regards,
        Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 22:35:33 +0000

Hideki,

Correct, but such LSP that can only accept packets from a single interface is very niche application and not generic enough to define an UPMEP for it. We need a definition that is applicable to LSPs in general.

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 13, 2013 3:31 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working grouplast call o

Sharam,

Very simple question.

Thanks,
Hideki Endo

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Mar 2013 22:36:49 +0000

Hi Shahram,
I think that we came to state of declaring personal preferences and discussing specifics of various implementations.

    Best regards,
        Greg

Hi Greg,

Thx
SD

Hi Shahram,

    Regards,
        Greg

Regards,
Shahram

    Regards,
        Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 07:46:36 +0900

Sharam,

Yes niche, but possible.

If there are any possibilities,
we MUST NOT preclude the possibilities in an international standard.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 22:57:25 +0000

Hideki,

The question is if the span of PWs and the LSP are the same (they start and end on same interface), then what is the point of monitoring the LSP? You can just monitor the PW. 

And I completely disagree that just because something is possible it has to be standardized. We need simple methods that are as generic as possible in standards. LSP UPMEP in my opinion adds a lot of complexity for not much apparent gain. 

Thx
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 13, 2013 3:47 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2ndworking grouplast

Sharam,

Yes niche, but possible.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 23:01:09 +0000

Greg,

You keep mentioning implementation. I am not arguing or discussing any implementation. I don't even care about implementation, but we should not ignore the fact that routers are implemented via Line-cards and switch fabrics.

Thx
Shahram

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 3:37 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Hi Shahram,

    Best regards,
        Greg

Thx
SD

Hi Shahram,

    Regards,
        Greg

Regards,
Shahram

    Regards,
        Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Mar 2013 23:16:23 +0000

Hi Shahram,
I don't see line cards and distinct switch fabric in what's called "pizza boxes", a.k.a. fixed configuration nodes.

True, some implementations would not be able to support UP MEP but, IMHO, that is not good enough reason not to define it and even less of good reason not to support in capable implementations.

    Regards,
        Greg

Sent: Wednesday, March 13, 2013 4:01 PM

Greg,

Thx
Shahram

Hi Shahram,

    Best regards,
        Greg

Thx
SD

Hi Shahram,

    Regards,
        Greg

Regards,
Shahram

    Regards,
        Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 13 Mar 2013 23:24:41 +0000

If IETF wants to define a MEP that only applies to pizza boxes, or only to Synthetic LM then be my guest.  But you have to state its applicability to any draft that defines it.

My recommendation is to not define such a restrictive entity.

Regards,
Shahram

On Mar 13, 2013, at 4:16 PM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shahram,

    Regards,
        Greg

Greg,

You keep mentioning implementation. I am not arguing or discussing any implementation. I don’t even care about implementation, but we should not ignore the fact that routers are implemented via Line-cards and switch fabrics.

Thx
Shahram

Hi Shahram,

    Best regards,
        Greg

Correct, but we can’t define a MEP that can only support a subset of OAM specially the less desirable ones. Besides Synthetic loss is not accurate and as far as I know, not many users are interested in Synthetic loss.

Thx
SD

Hi Shahram,

    Regards,
        Greg

Regards,
Shahram

    Regards,
        Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Mar 2013 02:40:04 +0100

Working Group,

this wg last call has been closed.

There have been comments, could the authors please review these
comments and if necessary update the document.

/Loa
for the wg chairs

--

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 19:59:52 +0900

Sharam,

I'm not sure what you want to do.

Currently, there is no RFC restricting to DOWN-MEP as you know,
which means that there is no consensus on the restriction in MPLS WG.

If you want to standardize the restriction,
what you should do is to submit new draft to make a consensus.

IMO, considering future extention,
unnecessary restriction MUST NOT be defined at this point.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 14 Mar 2013 16:55:03 +0000

I just asked that the figures in mip-mep-map draft be changed to Down-MEP, instead of UP-MEP.

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 4:00 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE: [mpls]2ndworking grou

Sharam,

Thanks,
Hideki Endo

---

From: Pablo Frank <[email-masked]>
Date: Thu, 14 Mar 2013 13:48:00 -0400

Shahram,

I think you ask an interesting fundamental question below. i.e. what is the
interface that an LSP up-MEP really associated with?  IMHO, it's not the
PWE interfaces.  A MEP cannot live on multiple interfaces simultaneously.
 Furthermore, a MEP that is meant to monitor a tunnel has no business
operating on an interface in a completely different network layer.  We know
that an up-MEP must appear before the "forwarding" function but I struggle
to find a good definition for what the MPLS forwarding function really
encompasses.

If I look to RFC 3031, one is tempted to define the MPLS forwarding
function as the combination of the ILM/FEC+NHLFE.  A related question is
"where does the LSP begin"?  According to 3031, the new label is imposed by
the NHLFE.  So does that mean that tunnels begin *after* the forwarding
function, or is it "during"/"before"?  If it's after, then I have a hard
time accepting that an up-MEP for tunnels even exists.  OTOH, something
like a P2MP LSP does not fit well with this model.  Surely in P2MP, the act
of multicasting the frame is part of the forwarding function?

IEEE 802.1q solves this problem by creating a virtual interface (i.e. the
CBP) inside an IB-BEB for the tunnel up-MEPs to live on.  I know of no
equivalent concept in MPLS so we would likely have to define something to
be able to move forward on the concept of an LSP up-MEP.  But it seems to
me that if an LSP up-MEP exists, it sits on some-yet-to-be-determined
object that is somewhere between the PWE interfaces and the MPLS forwarding
function.

I suspect that we'll get nowhere if we focus on implementation-specific
perspectives.  The answer has to be derived from the architecture of MPLS
and PWEs.

regards,
Pablo

On Wed, Mar 13, 2013 at 3:55 PM, Shahram Davari <[email-masked]> wrote:

>  Greg,****
>
> ** **
>
> We have a fundamental difference of opinion.  I have been involved in the
> OAM for over a decade now and one of the fundamental architectural
> requirements is that OAM packets MUST follow the data packets in the
> network and inside a switch/router up to the observation point (MEP). So it
> is not acceptable for data packets to be on Interface A and for MEP to be
> on Interface B. ****
>
> ** **
>
> In the example I gave, can you please tell me how you can do Loss
> Measurement for the LSP with UP-MEP? How do you increment the LSP UP-MEP
> receive LM counters for packets received from PW-A and PW-B? and where is
> the LSP-UP-MEP located?****
>
> ** **
>
> Thx
> Shahram****
>
> ** **
>
> *From:* Gregory Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, March 13, 2013 12:42 PM
>
> *To:* Shahram Davari; [email-masked]
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working
> group last call ondraft-ietf-mpls-tp-mip-mep-map)****
>
>  ** **
>
> Hi Shahram,****
>
> UP MEP, whether as defined by RFC 6371 or as defined elsewhere, e.g. IEEE
> 802.1ag, is not required to be co-located with an ingress to monitored
> service, e.g. attachement circuit, but with logical interface that
> represents monitored service. Location of UP MEP is undefined as long as it
> complies with where is sends to and receives from OAM packets/frames. In
> case of MPLS this element if MPLS forwarding function, in case of Ethernet
> - Bridge Relay Entity. For MPLS, as long as OAM packets sent to forwarding
> and get proper encapsulation, IMHO, we have ourselves an UP MEP. How packet
> being bounced within a node to get such treatment, I think, is
> implementation specific.****
>
>  ****
>
>     Regards,****
>
>         Greg****
>
> ** **
>  ------------------------------
>
> *From:* Shahram Davari [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, March 13, 2013 11:59 AM
> *To:* Gregory Mirsky; [email-masked]
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working
> group last call ondraft-ietf-mpls-tp-mip-mep-map)****
>
> Greg,****
>
> ** **
>
> RFC6371 is very high level and does not define whether UP MEP applies to
> LSP or PW.  Assume there are 2 ingress interfaces A & B. Each interface
> maps Ethernet traffic to its own PW (PW-A and PW-B). Now assume both these
> PWs go inside the same LSP that exists Interface C. Now please explain if
> we were to have an UP-MEP for LSP then on which interface would that LSP
> UP-MEP reside? Interface A? B? C?****
>
> ** **
>
> This simple example shows you can’t have an LSP UP-MEP.****
>
> ** **
>
> Thx
> SD****
>
> ** **
>
> *From:* Gregory Mirsky [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, March 12, 2013 11:56 AM
> *To:* Shahram Davari; [email-masked]
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group
> last call ondraft-ietf-mpls-tp-mip-mep-map)****
>
> ** **
>
> Dear All,****
>
> What would be the most appropriate subject to continue this discussion?
> I'll give it a try, please feel free to change it. ****
>
>  ****
>
> I think that there's nothing that can preclude from supporting UP MEP on
> MPLS-TP LSP, according to UP MEP definition of RFC 6371, even when
> multpiple PWs mapped to that LSP. Same, I think, is the true for  p2mp PW.
> Note that service, VPWS, is not part of MPLS-TP architecture.****
>
>  ****
>
>         Regards,****
>
>                 Greg****
>
>  ****
>
> -----Original Message-----****
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Shahram Davari****
>
> Sent: Tuesday, March 12, 2013 11:30 AM****
>
> To: [email-masked]****
>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]****
>
> Subject: Re: [mpls] 2nd working group last call
> ondraft-ietf-mpls-tp-mip-mep-map****
>
>  ****
>
> Hideki,****
>
>  ****
>
> So far no RFC or draft has talked about Down or UP MEP for LSPs. But if
> you think about it logically LSPs can't have UP-MEP because LSP can carry
> many PWs and each PW may enter the LSP from a different port/interface.
> PWs can have UP-MEP but only for P2P services (VPWS), otherwise they can't
> have UP-MEP either (same as LSP).****
>
>  ****
>
> My suggestion is to correct figures and change UP-MEPs to Down-MEPs for
> LSPs. Also to mention UP-MEP is out of scope.****
>
>  ****
>
> Thx****
>
> SD****
>
>  ****
>
> -----Original Message-----****
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>
> ]****
>
> Sent: Tuesday, March 12, 2013 11:20 AM****
>
> To: Shahram Davari****
>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]*
> ***
>
> Subject: Re:Re: [mpls] 2nd working group last call
> ondraft-ietf-mpls-tp-mip-mep-map****
>
>  ****
>
> Hi Shahram,****
>
>  ****
>
> Just one comment.****
>
>  ****
>
> >I would also argue that LSPs can't have UP-MEPs, since PWs from many
> ingress ports can enter an LSP  and therefore the LSP can't start on the
> ingress interface.****
>
>  ****
>
> I think this depends on implementations.****
>
> Any RFC don't restrict to DOWN-MEPs in an LSP.****
>
>  ****
>
> Anyway, MEP mechanism is out of scope in this draft as you said.****
>
>  ****
>
> Thanks,****
>
> Hideki Endo****
>
>  ****
>
> >Hi,****
>
> >** **
>
> >Although I mentioned I am Ok with the draft to be advanced to RFC, but
> after reviewing it in more details it appears that the draft, in spite of
> its name, does talk about UP-MEP at all and only talks about UP-MIP, while
> the figures show UP-MEPs for LSPs.  Even if the scope of the draft is
> UP-MIP, considering that there can't be a MIP without a MEP,  the draft
> should have some wording regarding UP-MEPs and their applicability to LSPs
> and PWs. I would also argue that LSPs can't have UP-MEPs, since PWs from
> many ingress ports can enter an LSP  and therefore the LSP can't start on
> the ingress interface.****
>
> >** **
>
> >A quick fix at this point is to mention UP-MEP is out of scope and change
> the figures to only show Down-MEPs. A better fix is to elaborate on UP-MEP
> and its applicability and placement, etc.****
>
> >** **
>
> >Regards,****
>
> >Shahram****
>
> >** **
>
> > ****
>
> >** **
>
> >-----Original Message-----****
>
> >From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of ****
>
> >Shahram Davari****
>
> >Sent: Wednesday, March 06, 2013 11:30 AM****
>
> >To: Loa Andersson; [email-masked]****
>
> >Cc: <[email-masked]>; [email-masked]; ** **
>
> >[email-masked]****
>
> >Subject: Re: [mpls] 2nd working group last call on ****
>
> >draft-ietf-mpls-tp-mip-mep-map****
>
> >** **
>
> >My Comments are addressed and I support this draft to be published as
> Informational  RFC.****
>
> >** **
>
> >Thx****
>
> >Shahram****
>
> >** **
>
> >-----Original Message-----****
>
> >From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of ****
>
> >Loa Andersson****
>
> >Sent: Tuesday, February 26, 2013 3:02 AM****
>
> >To: [email-masked]****
>
> >Cc: <[email-masked]>; [email-masked]; ** **
>
> >[email-masked]****
>
> >Subject: [mpls] 2nd working group last call on ****
>
> >draft-ietf-mpls-tp-mip-mep-map****
>
> >** **
>
> >Working Group,****
>
> >** **
>
> >draft-ietf-mpls-tp-mip-mep-map-05.txt has been updated after a previous *
> ***
>
> >last call, due to the nature a and extent of the updates we have chosen *
> ***
>
> >to start a 2nd wg last call.****
>
> >** **
>
> >The IETF datatracker status page for this draft is:****
>
> >https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map****
>
> >** **
>
> >There's also a htmlized version available at:****
>
> >http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-05****
>
> >** **
>
> >A diff from the previous version is available at:****
>
> >http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-mip-mep-map-05****
>
> >** **
>
> >Please send your comments, including approval of the documents and the **
> **
>
> >updates to the mpls working group list ([email-masked])****
>
> >** **
>
> >This working group last call ends March 13, 2013.****
>
> >** **
>
> >/Loa****
>
> >for the MPLS working group co-chairs****
>
> >--****
>
> >** **
>
> >** **
>
> >Loa Andersson                        email: [email-masked]****
>
> >Senior MPLS Expert                          [email-masked]****
>
> >Huawei Technologies (consult)        phone: +46 739 81 21 64****
>
> >_______________________________________________****
>
> >mpls mailing list****
>
> >[email-masked]****
>
> >https://www.ietf.org/mailman/listinfo/mpls****
>
> >** **
>
> >** **
>
> >_______________________________________________****
>
> >mpls mailing list****
>
> >[email-masked]****
>
> >https://www.ietf.org/mailman/listinfo/mpls****
>
> >** **
>
> >** **
>
> >_______________________________________________****
>
> >mpls mailing list****
>
> >[email-masked]****
>
> >https://www.ietf.org/mailman/listinfo/mpls****
>
> >** **
>
>  ****
>
>  ****
>
> _______________________________________________****
>
> mpls mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/mpls****
>
>  ****
>

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 02:55:01 +0900

Sharam,

What's reason to change?

Again, currently, there is no RFC restricting to DOWN-MEP as you know.
And, the fugure in our draft is just example.

Here, what I'd like to make clear is that
our draft focuses on only MIP targetting framework.
This means MEP definition is out of scope in our darft,
but should be in RFC6371.
If you want to add/remove something to/from MEP definition,
you should talk with the authors of RFC6371.

If there is one reason for me to change the fugure in our draft,
Down-MEP may be more popular than Up-MEP.
Normally, An example should be described using the most popular case.
If you say so, it is possible to consider to change.

Thanks,
Hideki Endo

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 14 Mar 2013 18:00:48 +0000

Heidi,

That is exactly my point. Since there is no argument about Down-MEP and everyone agrees Down-MEP LSP is possible and most useful and applies to any application, then I suggest changing UP-MEPs in your figures to Down-MEPs. 

My concern is that if in future someone writes a draft about Down-MEP and UP-MEP for PW and LSP and the decision is not to have LSP UP_MEP, then your RFC will require change.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 10:55 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:RE: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE:[mpls]2ndworkin

Sharam,

What's reason to change?

Thanks,
Hideki Endo

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 14 Mar 2013 18:11:47 +0000

Hi Shahram,
I can not agree with your characterization "... everyone agrees Down-MEP LSP is ... most useful ...". I'll note that for Ethernet OAM Down MEP suggested for physical level, i.e. link layer, while Up MEP used for service level. I agree with Pablo and will re-state expressed in the beginning Up and Down MEP are related to monitored object, not to clients of such object.

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 11:01 AM
To: [email-masked]
Cc: Gregory Mirsky; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Re:RE: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE:[mpls]2ndworkin

Heidi,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 10:55 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:RE: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE:[mpls]2ndworkin

Sharam,

What's reason to change?

Here, what I'd like to make clear is that our draft focuses on only MIP targetting framework.
This means MEP definition is out of scope in our darft, but should be in RFC6371.
If you want to add/remove something to/from MEP definition, you should talk with the authors of RFC6371.

If there is one reason for me to change the fugure in our draft, Down-MEP may be more popular than Up-MEP.
Normally, An example should be described using the most popular case.
If you say so, it is possible to consider to change.

Thanks,
Hideki Endo

>Cc: [email-masked]; [email-masked]; 
>[email-masked]; 
>Currently, there is no RFC restricting to DOWN-MEP as you know, which 
>means that there is no consensus on the restriction in MPLS WG.
>
>If you want to standardize the restriction, what you should do is to 
>submit new draft to make a consensus.
>
>>Cc: [email-masked]; [email-masked]; 
>>[email-masked]; 
>>>Cc: [email-masked]; [email-masked]; 
>>>[email-masked]; 
>>>>Assume there are 2 ingress interfaces A & B. Each interface maps 
>>>>Ethernet traffic to its own PW (PW-A and PW-B). Now assume both these PWs go inside the same LSP that exists Interface C.
>>>"Assume there are 1 ingress interfaces A. Two VLAN flows in the 
>>>interface A are mapped  to different PWs (PW-A and PW-B). Now assume both these PWs go inside the same LSP."
>>>>Subject: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group 
>>>>last call ondraft-ietf-mpls-tp-mip-mep-map)
>>>>
>>>>Dear All,
>>>>From: [email-masked]<mailto:[email-masked]> 
>>>>[mailto:[email-masked]] On Behalf Of Shahram Davari
>>>>Cc: [email-masked]<mailto:[email-masked]>; 
>>>>[email-masked]<mailto:[email-masked]>; 
>>>>[email-masked]<mailto:draft-ietf-mpls
>>>>[email-masked]>; 
>>>>[email-masked]<mailto:[email-masked]>
>>>>ondraft-ietf-mpls-tp-mip-mep-map
>>>>
>>>>Hideki,
>>>>
>>>>Cc: [email-masked]<mailto:[email-masked]>; 
>>>>[email-masked]<mailto:[email-masked]>; 
>>>>[email-masked]<mailto:[email-masked]>; 
>>>>[email-masked]<mailto:[email-masked]>; 
>>>>ondraft-ietf-mpls-tp-mip-mep-map
>>>>
>>>>Hi Shahram,
>>>>
>>>>Just one comment.
>>>>
>>>>>From: [email-masked]<mailto:[email-masked]> 
>>>>>[mailto:[email-masked]] On Behalf Of Shahram Davari
>>>>>Cc: <[email-masked]<mailto:[email-masked]>>; 
>>>>>[email-masked]<mailto:[email-masked]>;
>>>>>From: [email-masked]<mailto:[email-masked]> 
>>>>>[mailto:[email-masked]] On Behalf Of Loa Andersson
>>>>>Cc: <[email-masked]<mailto:[email-masked]>>; 
>>>>>[email-masked]<mailto:[email-masked]>;
>>>>>the updates to the mpls working group list 
>>>>>([email-masked]<mailto:[email-masked]>)
>>>>>

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 14 Mar 2013 18:20:05 +0000

Hi,

In any case I am not convinced about the possibility or usefulness of an UP-MEP LSP. So I categorize it as controversial. Due to this reason I am asking it to be removed from this draft before I vote yes to this last call.

Thx
SD

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 11:12 AM
To: Shahram Davari; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Re:RE: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE:[mpls]2ndworkin

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 11:01 AM
To: [email-masked]
Cc: Gregory Mirsky; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Re:RE: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE:[mpls]2ndworkin

Heidi,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 10:55 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:RE: Re:RE: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE:[mpls]2ndworkin

Sharam,

What's reason to change?

Thanks,
Hideki Endo

>>>>[email-masked]>