Subject: Re: [mpls] New version of draft-boutros-mpls-tp-loopback-01

From: Mach Chen <[email-masked]>
Date: Mon, 23 Mar 2009 11:55:24 +0800

Hi Sami,

Questions about your draft...

1. What's the application scenarios of lock funciton? Does there really need 
the lock function?

2. In FLB mode, how does node A determine which data is permited to be 
transmitted along with the being tested MPLS-TP LSP? It seems that only the 
data generated by node A could be transmitted on to the MPLS-TP, is my 
understanding correct?

Best regards,
Mach

--------------------------------------------------
From: "Sami Boutros" <[email-masked]>
Sent: Friday, November 07, 2008 1:09 AM
To: "Loa Andersson" <[email-masked]>; <[email-masked]>
Cc: "Siva Sivabalan (msiva)" <[email-masked]>; "David Ward" 
<[email-masked]>
Subject: [mpls] New version of draft-boutros-mpls-tp-loopback-01

> Please find the updated version of the draft @
>
> http://www.tla-group.com/~loa/draft-boutros-mpls-tp-loopback-01.txt
>
> Thanks,
>
> Sami
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Nitin Bahadur <[email-masked]>
Date: Sun, 22 Mar 2009 21:52:08 -0700

Hi Sami,

   I have a few meta questions on your draft.

1) Can you clarify if this loopback function is applicable just to MPLS-TP
or also to MPLS LSPs in general.

2) You mention that a MPLS-TP LSP can be set into FLB or OLB mode. I presume
the *unlock OAM packets* will not be looped back. Can you please clarify
that ?

3) I am not clear on the motivation for OAM loopback mode. Can you clarify
why we need a OAM loopback mode ?
 
4) Section 4.5 - Auth TLV. If the message is sent in-band, do we need a
auth-tlv ? Was there any requirement (in some requirement draft) to have
auth for loopback mode?

5) Section 4.9 - Data packets. The optional seq-id solution seems a little
half-baked. At the least, the id should be a 64-bit field.

6) Section 4.10 - NMS. This section seems to specify requirements and no
real solution. I'm not sure why this section is part of your draft. Your
draft does not seem to add anything new to enable a NMS to do something.

7) Finally, you have defined a new encap mechanism for TLVs. Any particular
reason that the lsp-ping packet cannot be enclosed after the ACH header? Can
we just re-use the lsp-ping packet formats....they seem to have a whole
bunch of things that you are re-defining.

Thanks
Nitin

---

From: Loa Andersson <[email-masked]>
Date: Mon, 23 Mar 2009 16:25:44 +0100

Nitin,

> or also to MPLS LSPs in general.

there has been a requirement from the start of the mpls-tp project that
all the mpls-tp solutions, and in particular the OAM part, should be
possible to use with "classical mpls".

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: Sami Boutros <[email-masked]>
Date: Mon, 23 Mar 2009 09:48:51 -0700

Hi Mach,

At 08:55 PM 3/22/2009, Mach Chen wrote:
>1. What's the application scenarios of lock funciton? Does there 
>really need the lock function?

The Lock function is needed only in FLB mode since this will be data 
traffic impacting.

>2. In FLB mode, how does node A determine which data is permited to 
>be transmitted along with the being tested MPLS-TP LSP? It seems 
>that only the data generated by node A could be transmitted on to 
>the MPLS-TP, is my understanding correct?

Correct Data will be transmitted from the ingress PE where the 
MPLS-TP LSP starts.

Thanks,

Sami

>Cc: "Siva Sivabalan (msiva)" <[email-masked]>; "David Ward" <[email-masked]>

---

From: Sami Boutros <[email-masked]>
Date: Mon, 23 Mar 2009 10:01:52 -0700

Hi Nitin,

Please have a look at the 02 version.

>or also to MPLS LSPs in general.

They are applicable for MPLS LSP's in general.

>the *unlock OAM packets* will not be looped back. Can you please clarify

Sure.

>why we need a OAM loopback mode ?

in draft-ietf-mpls-tp-oam-requirements-01.txt need of loopback function is
mentioned for connection verification and for 2 ways delay measurements.

>auth-tlv ? Was there any requirement (in some requirement draft) to have

Good point will ask to add this requirement to the requirement doc for OAM
intrusive functions.

>half-baked. At the least, the id should be a 64-bit field.

Will look into that.

>draft does not seem to add anything new to enable a NMS to do something.

This is a TBD section need more work.

>bunch of things that you are re-defining.

We made the message format in 02 very similar to the LSP ping Message format.

Thanks,

Sami

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 28 Mar 2009 08:27:09 +0000

Colleagues,

> Good point will ask to add this requirement to the requirement doc for OAM

Although I haven't read the draft (sorry Sami!), I can see need for
authentication for loopback.

One use case I am looking at where I need performance monitoring includes
placing T-PEs on unsecured customer premises. Although not foolproof use of
authentication may be required to lessen exposure of my network to attack
vectors through the performance monitoring mechanism.

Ben