Subject: [mpls-tp] Concerns Re: poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 May 2010 11:45:45 -0700

Dear Nurit,
I agree that the document has technical merit as well as it has issues to be
worked on. I as well support, not without reservations, adoption of the
document by the WG to move work forward. But I'm concerned by three facts:

   - narrowed scope of the revisited document
   - pressure of schedule (real or imagined)
   - lack of alternatives to BFD especially in light of its challenges in
   p2p and p2mp unidirectional paths.

I think that MPLS-TP OAM Analysis laid good foundation for technical
discussion of at least two sources for MPLS-TP OAM - BFD and Y.1731.
Personally, I'd like either such discussion to precede selection of one one
by the WG  or let both, not a rare case in IETF, onto standardization path.

Regards,
Greg

On Wed, May 19, 2010 at 11:04 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
[email-masked]> wrote:

> Adopting a document as a WG document does not indicate that it is ready for
> publication. It just indicates that the WG is interested to work on this
> topic.
> It is natural that in such a state of the document, there are many areas on
> which is needed. Still this should not prevent us adopting it as a WG
> document. We can continue resolving the open issues and work on the document
> as a WG document.
> As indicated before, I support the adoption of the document as a WG
> document and welcome everyone to contribute to the content in order to make
> it a good document.
> Best regards,
> Nurit
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext [email-masked]
> Sent: Wednesday, May 19, 2010 7:53 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an
> mplsworking group document
>
> Valid input.
> I agree with it.
>
> Mircea
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of BUSI, ITALO (ITALO)
> Sent: 19 May 2010 18:16
> To: Loa Andersson; [email-masked]
> Cc: MPLS-TP ad hoc team
> Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls
> working group document
>
> While draft-asm provides some useful basis, the following
> capabilities/technical concerns need to be addressed before progressing this
> draft to WG status:
>
> - running BFD at a fixed operator's configurable rate.
> - Unidirectional path support
> - One mechanism that can work independently from the protection switching
> configuration
>
> Italo
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Loa Andersson
> > Sent: martedì 11 maggio 2010 21.41
> > To: [email-masked]; CCAMP WG; [email-masked]; [email-masked];
> > MPLS-TP ad hoc team
> > Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv
> > an mpls working group document
> >
> > All,
> >
> > this is start a two week poll on making
> >
> > http://www.ietf.org/internet-drafts/draft-asm-mpls-tp-bfd-cc-cv-04.txt
> >
> > an mpls working group document.
> >
> > To respond to the poll please send a mail to the mpls-tp
> > mailing list indicating "yes/support" or "no/do not support".
> >
> > Reviews, comments on the draft, or motivation for support or
> > non-support should be sent to the same mailing list, but with
> > another subject.
> >
> > The poll ends eob May 25th.
> >
> > /Loa
> >
> >
> > --
> >
> >
> > Loa Andersson                         email:
> > [email-masked]
> > Sr Strategy and Standards Manager            [email-masked]
> > Ericsson Inc                          phone: +46 10 717 52 13
> >                                               +46 767 72 92
> > 13 _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 May 2010 21:01:05 +0200

Hi,

Thanks for your response and insight.

I think we should have technical discussion (and I would encourage all those that vote no to indicate why their vote was so, on a pure technical case). 

I think we should have one solution for each problem statement. I do not think it is good for the industry where open and interoperable solutions are needed to have many solutions to the same problem. 

Best regards,

Nurit 

From: ext Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, May 19, 2010 9:46 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Concerns Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Dear Nurit,
I agree that the document has technical merit as well as it has issues to be worked on. I as well support, not without reservations, adoption of the document by the WG to move work forward. But I'm concerned by three facts:

*	narrowed scope of the revisited document
*	pressure of schedule (real or imagined)
*	lack of alternatives to BFD especially in light of its challenges in p2p and p2mp unidirectional paths.

I think that MPLS-TP OAM Analysis laid good foundation for technical discussion of at least two sources for MPLS-TP OAM - BFD and Y.1731. Personally, I'd like either such discussion to precede selection of one one by the WG  or let both, not a rare case in IETF, onto standardization path.

Regards,
Greg

On Wed, May 19, 2010 at 11:04 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]> wrote:

Adopting a document as a WG document does not indicate that it is ready for publication. It just indicates that the WG is interested to work on this topic.
It is natural that in such a state of the document, there are many areas on which is needed. Still this should not prevent us adopting it as a WG document. We can continue resolving the open issues and work on the document as a WG document.
As indicated before, I support the adoption of the document as a WG document and welcome everyone to contribute to the content in order to make it a good document.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

While draft-asm provides some useful basis, the following capabilities/technical concerns need to be addressed before progressing this draft to WG status:

- running BFD at a fixed operator's configurable rate.
- Unidirectional path support
- One mechanism that can work independently from the protection switching configuration

Italo

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 May 2010 22:01:25 +0300

Greg,
One brief comment if you do not mind.

IMO Y.1731 does not provide a viable alternative to BFD for p2mp and p2p unidirectional paths because in Ethernet (which is the scope of Y.1731) these things simply do not exist.  Ethernet services are either bi-directional p2p, or bi-directional mp2mp, so that the return path (which is a real problem of OAM for unidirectional paths in MPLS-TP) always exists.

The down side of Y.1731 as the base for MPLS-TP OAM is, IMO, is heavy dependence on the Ethernet data plane (e.g., its usage of well-known multicast addresses for addressing "all MEPs" or "all MEPS and MIPs". The MPLS-TP data plane does not provide this functionality.

My 2c,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, May 19, 2010 2:46 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] Concerns Re: poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Dear Nurit,

Regards,
Greg
On Wed, May 19, 2010 at 11:04 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]<mailto:[email-masked]>> wrote:
Adopting a document as a WG document does not indicate that it is ready for publication. It just indicates that the WG is interested to work on this topic.
It is natural that in such a state of the document, there are many areas on which is needed. Still this should not prevent us adopting it as a WG document. We can continue resolving the open issues and work on the document as a WG document.
As indicated before, I support the adoption of the document as a WG document and welcome everyone to contribute to the content in order to make it a good document.
Best regards,
Nurit

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]<mailto:[email-masked]>
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loa Andersson
> To: [email-masked]<mailto:[email-masked]>; CCAMP WG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> MPLS-TP ad hoc team
> [email-masked]<mailto:[email-masked]>
> Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 19 May 2010 14:03:02 -0500

I agree with Greg's wisdom that it would be better to discuss the two solution sources identified in the OAM Analysis draft.

I further agree that there seems to be schedule pressures that are motivating the call for this document to move to WG status.

I do not support this draft moving forward to WG status before having more information on how the gaps are going to be resolved.

Jonathan Sadler
Sent: Wednesday, May 19, 2010 1:46 PM

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]<mailto:[email-masked]>
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 May 2010 12:08:24 -0700

Dear Sasha,
appreciate your contribution (every cent counts!) ;)
I agree that Y.1731-based OAM likely would not be better for unidirectional
MPLS-TP connections than BFD and will have to address return path issue as
you've mentioned. Perhaps more so, Y.1731 will use MPLS-TP identifiers as
much as OAM based on BFD. But should these similarities negate the
discussion?

Regards,
Greg

On Wed, May 19, 2010 at 12:01 PM, Alexander Vainshtein <
[email-masked]> wrote:

> IMO Y.1731 does not provide a viable alternative to BFD for p2mp and p2p
> unidirectional paths because in Ethernet (which is the scope of Y.1731)
> these things simply do not exist.  Ethernet services are either
> bi-directional p2p, or bi-directional mp2mp, so that the return path (which
> is a real problem of OAM for unidirectional paths in MPLS-TP) always exists.
>
>
>
> The down side of Y.1731 as the base for MPLS-TP OAM is, IMO, is heavy
> dependence on the Ethernet data plane (e.g., its usage of well-known
> multicast addresses for addressing “all MEPs” or “all MEPS and MIPs”. The
> MPLS-TP data plane does not provide this functionality.
>
>
>
> My 2c,
>
>      Sasha
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Greg Mirsky
> *Sent:* Wednesday, May 19, 2010 2:46 PM
> *To:* Sprecher, Nurit (NSN - IL/Hod HaSharon)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [mpls-tp] Concerns Re: poll on making
> draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document
>
>
>
> Dear Nurit,
> I agree that the document has technical merit as well as it has issues to
> be worked on. I as well support, not without reservations, adoption of the

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 May 2010 21:19:39 +0200

Hi,

I am not sure what people mean by Y.1731. Is it the frame format that they refer to or is it the functionality? 

For the frame format, we already discussed it many times in the past and we can restart it again - personally see a lot of disadvantages in doing so and I can re-explain ( in another context of discussion). In any case it will not be the same as in Ethernet, and even if it is, many of the information will not be used. 

But I do not see why one should care about frame format, but they should care of functionality and operational experience. 

We have requirements for OAM in MPLS-TP and we should provide a solution that applies to the requirements. 

I would like to see technical discussion on the proposed solution, in relation to the requirements. 

I would expect all those that voted No to explain on a technical base what are the issues they see, and why these cannot be resolved while the document is a WG document. Sometime it looks to me that people believe that a document being adopted as WG document is just ready for publication. 

Best regards,

Nurit

From: ext Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, May 19, 2010 10:08 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: Re: [mpls-tp] Concerns Re: poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Dear Sasha,
appreciate your contribution (every cent counts!) ;)
I agree that Y.1731-based OAM likely would not be better for unidirectional MPLS-TP connections than BFD and will have to address return path issue as you've mentioned. Perhaps more so, Y.1731 will use MPLS-TP identifiers as much as OAM based on BFD. But should these similarities negate the discussion?

Regards,
Greg

On Wed, May 19, 2010 at 12:01 PM, Alexander Vainshtein <[email-masked]> wrote:

Greg,

My 2c,

     Sasha

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 May 2010 12:59:48 -0700

Dear Nurit,
I agree that discussion must look beyond the mere format though richness of
format reflects in functionality and operational experience.
As for re-using Base BFD for bidirectional p2p MPLS-TP connections I see
that we're modifying some parts (demultiplexing of sessions between two
nodes, session parameters negotiation) and likely to exclude others (echo,
poll, demand mode). What's left then? Not more than BFD PDU.

Regards,
Greg

On Wed, May 19, 2010 at 12:19 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
[email-masked]> wrote:

> For the frame format, we already discussed it many times in the past and we
> can restart it again – personally see a lot of disadvantages in doing so and
> I can re-explain ( in another context of discussion). In any case it will
> not be the same as in Ethernet, and even if it is, many of the information
> will not be used.
>
> *But I do not see why one should care about frame format*, but they should
> care of *functionality* and *operational experience*.
>
> I would expect all those that voted No to explain on a technical base what
> are the issues they see, and why these cannot be resolved while the document
> is a WG document. Sometime it looks to me that people believe that a
> document being adopted as WG document is just ready for publication.
>
> Best regards,
>
> Nurit
>
>
>
> *From:* ext Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, May 19, 2010 10:08 PM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]; [email-masked]; Sprecher, Nurit (NSN -
> IL/Hod HaSharon)
> *Subject:* Re: [mpls-tp] Concerns Re: poll on making
> draft-asm-mpls-tp-bfd-cc-cv an mpls working group document
>
>
>
> Dear Sasha,

---

From: Yang Yang <[email-masked]>
Date: Wed, 19 May 2010 22:19:22 +0200

Hello all,

    Y.1731 isn't used directly as MPLS-TP OAM. The mechanism will be
adopted. It's Y.1731-based MPLS-TP OAM. It is independent of Ethernet.

Best Regards!
   Yang

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 May 2010 22:42:13 +0200

Do you mean that the mechanism will be adopted or will be proposed?

At least the individual draft on Y.1731 just refers to encapsulation, (and IMO not efficient one). 

The intention is to satisfy the requirements for MPLS-TP OAM (which I think are based on the operation experience of transport networks). 

draft-asm-mpls-tp-bfd-cc-cv  intends to satisfy the requirements and provide the required functionality. There is of course a need for more work and some issues need to be resolved, but this can be done on a WG document as well. 

I think we should look at the document and have a technical discussion with relation to the requirements. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Yang Yang
Sent: Wednesday, May 19, 2010 11:19 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Concerns Re: poll on makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Hello all, 

    Y.1731 isn't used directly as MPLS-TP OAM. The mechanism will be adopted. It's Y.1731-based MPLS-TP OAM. It is independent of Ethernet. 

Best Regards!

   Yang

On Wed, May 19, 2010 at 9:01 PM, Alexander Vainshtein <[email-masked]> wrote:

Greg,

My 2c,

     Sasha

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: Yang Yang <[email-masked]>
Date: Wed, 19 May 2010 22:49:17 +0200

Hello Nurit,

   Could you make it clear about the difference between adopted and
proposed?

   There is one question. Could draft-asm-* support all the required MPLS-TP
OAM functions like route tracing?  Before we move on, we should make sure
that the solution we choose will provide alll the functions required.

Best Regards!
  Yang

On Wed, May 19, 2010 at 10:42 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
[email-masked]> wrote:

> The intention is to satisfy the requirements for MPLS-TP OAM (which I think
> are based on the operation experience of transport networks).
>
> draft-asm-mpls-tp-bfd-cc-cv  intends to satisfy the requirements and
> provide the required functionality. There is of course a need for more work
> and some issues need to be resolved, but this can be done on a WG document
> as well.
>
> Behalf Of *ext Yang Yang
> *Sent:* Wednesday, May 19, 2010 11:19 PM
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [mpls-tp] Concerns Re: poll on
> makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document
>
>
>
> Hello all,
>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 May 2010 23:49:49 +0300

Yang,
I would be very happy to hear some details on adapting Y.1731 to the following hard facts of life in the MPLS/MPLS-T data plane environment:

·         Addressing of MEPs and MIPs (groups and individual ones)

·         Fate-sharing of OAM and user traffic, esp. in the case of linktrace messages.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yang Yang
Sent: Wednesday, May 19, 2010 4:19 PM
To: Alexander Vainshtein
Cc: Greg Mirsky; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Concerns Re: poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Hello all,

Best Regards!
   Yang

On Wed, May 19, 2010 at 9:01 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Greg,
One brief comment if you do not mind.

My 2c,
     Sasha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Wednesday, May 19, 2010 2:46 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [mpls-tp] Concerns Re: poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]<mailto:[email-masked]>
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 May 2010 23:17:21 +0200

Hi,

Draft-asm is intended to provide pro-active cc & cv and RDI for MPLS-TP LSP, PWs and Sections. 

For route tracing we will have another tool, as already discussed in some drafts. 

I do not understand the question. 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Yang Yang
Sent: Wednesday, May 19, 2010 11:49 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Alexander Vainshtein; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Concerns Re: poll on makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Hello Nurit,

   Could you make it clear about the difference between adopted and proposed? 

   There is one question. Could draft-asm-* support all the required MPLS-TP OAM functions like route tracing?  Before we move on, we should make sure that the solution we choose will provide alll the functions required. 

Best Regards!

  Yang

On Wed, May 19, 2010 at 10:42 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]> wrote:

 

Hello all, 

Best Regards!

   Yang

Greg,

My 2c,

     Sasha

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: Yang Yang <[email-masked]>
Date: Wed, 19 May 2010 23:30:03 +0200

Hello Nurit,

    Instead to have many tools, why not use one tool to provide all the
functions? It will be nice if BFD could be extended for such use.

Best Regards!
   Yang

On Wed, May 19, 2010 at 11:17 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *ext Yang Yang
> *Sent:* Wednesday, May 19, 2010 11:49 PM
>
> *Cc:* Alexander Vainshtein; [email-masked]; [email-masked]
>
>    There is one question. Could draft-asm-* support all the required
> MPLS-TP OAM functions like route tracing?  Before we move on, we should make
> sure that the solution we choose will provide alll the functions required.
>
>
>
> Best Regards!
>
>   Yang
>
>
>
>
>
>
>

---

From: David Allan I <[email-masked]>
Date: Wed, 19 May 2010 17:44:09 -0400

HI Yang:

What constitutes one tool is in the eye of the beholder....Somthing that does everything all the time is implied by that statement, which IMO is not useful or desirable.

I look to BFD as a proactive tool, therefore I'd expect the design to be optimized accordingly. On demand tools have different scaling and functional requirements, hence again I'd want them designed accordingly...

"Horses for courses..." as they say...I would not want BFD extended to the point where scaling was inappropriately compromised simply to meet what I consider to be an artificial requirement...

cheers
D

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yang Yang
Sent: Wednesday, May 19, 2010 5:30 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Concerns Re: poll on makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Hello Nurit,

    Instead to have many tools, why not use one tool to provide all the functions? It will be nice if BFD could be extended for such use.

Best Regards!
   Yang

On Wed, May 19, 2010 at 11:17 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Draft-asm is intended to provide pro-active cc & cv and RDI for MPLS-TP LSP, PWs and Sections.
For route tracing we will have another tool, as already discussed in some drafts.
I do not understand the question.
Best regards,
Nurit

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Yang Yang
Sent: Wednesday, May 19, 2010 11:49 PM

To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hello Nurit,

Best Regards!
  Yang

On Wed, May 19, 2010 at 10:42 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]<mailto:[email-masked]>> wrote:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Yang Yang
Sent: Wednesday, May 19, 2010 11:19 PM
To: Alexander Vainshtein
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Concerns Re: poll on makingdraft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Hello all,

Best Regards!
   Yang

My 2c,
     Sasha

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]<mailto:[email-masked]>
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 May 2010 23:56:16 +0200

I would not consider Y.1731 as one tool. 

It is a set of tools, with different functionalities and different messages. 

Sent: Thursday, May 20, 2010 12:30 AM

Hello Nurit, 

Best Regards!

   Yang

On Wed, May 19, 2010 at 11:17 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]> wrote:

Hi,

Best regards,

Nurit

Hello Nurit,

Best Regards!

  Yang

 

Hello all, 

Best Regards!

   Yang

Greg,

My 2c,

     Sasha

Dear Nurit,

Regards,
Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 20 May 2010 08:27:53 +0200

Sasha,
 
> multicast addresses for addressing "all MEPs" or "all MEPS and MIPs". 
 
I believe that you misunderstand the forwarding in Ethernet p2p and p2mp
connections. In those p2p and p2mp Ethernet connections (i.e p2p and p2mp
VLANs) all frames are simply broadcast without inspection of the DA or SA
fields. The DA/SA fields are only inspected and used in the forwarding
process in rmp and mp2mp Ethernet connections (i.e. rmp and mp2mp VLANs).

Y.1731 OAM frames consists of four elements:
1) source port and destination port/port group identifier header
2) protocol type header
3) OAM common header
4) OAM specific functionality

These Y.1731 OAM frames may or may not be labelled (with a C-, S- or I-Tag).

Draft draft-bhh-mpls-tp-oam-y1731 specifies the reuse of 3) and 4) and
complement those two element with a G-Ach of which the Channel Type performs
the role of 2). 

This bhh MPLS-TP OAM packets may or may not be labelled (with a PW or
GAL+LSP label).

I.e. the Ethernet dataplane headers are replaced by the MPLS-TP dataplane
headers and the OAM common/specific elements are reused.

In Feb 2010 interworking tests between equipment of multiple vendors have
demonstrated the interoperability of such draft-bhh-mpls-tp-oam-y1731 based
MPLS-TP OAM. 

For unidirectional connections there is no requirement in transport networks
for a 'return path in unidirectional connections'. OAM tools in transport
networks are designed to function in 'bidirectional connections' and in
'unidirectional connections (without return path)'.

Rgards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: woensdag 19 mei 2010 21:01
To: Greg Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Concerns Re: poll on making
draft-asm-mpls-tp-bfd-cc-cvan mpls working group document

Greg,

The down side of Y.1731 as the base for MPLS-TP OAM is, IMO, is heavy
dependence on the Ethernet data plane (e.g., its usage of well-known
multicast addresses for addressing "all MEPs" or "all MEPS and MIPs". The
MPLS-TP data plane does not provide this functionality.

My 2c,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: Wednesday, May 19, 2010 2:46 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] Concerns Re: poll on making draft-asm-mpls-tp-bfd-cc-cv
an mplsworking group document

Dear Nurit,

*	narrowed scope of the revisited document 
*	pressure of schedule (real or imagined) 
*	lack of alternatives to BFD especially in light of its challenges in
p2p and p2mp unidirectional paths. 

Regards,
Greg

On Wed, May 19, 2010 at 11:04 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon)
<[email-masked]> wrote:

Adopting a document as a WG document does not indicate that it is ready for
publication. It just indicates that the WG is interested to work on this
topic.
It is natural that in such a state of the document, there are many areas on
which is needed. Still this should not prevent us adopting it as a WG
document. We can continue resolving the open issues and work on the document
as a WG document.
As indicated before, I support the adoption of the document as a WG document
and welcome everyone to contribute to the content in order to make it a good
document.
Best regards,
Nurit

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 20 May 2010 09:03:03 +0200

Nurit,
 
> I am not sure what people mean by Y.1731. Is it the frame format that they
refer to or is it the functionality? 
 
May I suggest to read draft-bhh-mpls-tp-oam-y1731, which can be download
from http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-04. Section 3 of
this draft presents the frame format details. After reading it should be
unambiguous what Y.1731 based MPLS-TP OAM PDUs are.
 
draft-bhh-mpls-tp-oam-y1731 specifies how the MPLS-TP OAM functionality can
be implemented by means of Y.1731 based OAM PDUs combined with MPLS-TP
headers. With Y.1731 OAM PDUs now being specified for 4 years and being used
in the networks for some years, there is a significant operational
experience with this type of OAM. Furthermore interworking of
draft-bhh-mpls-tp-oam-y1731 based implementations has been tested earlier
this year and was shown on the MPLS & Ethernet World congress in Paris.
 
MPLS-TP equipment must furthermore support rmp and mp2mp connections and for
this purpose MPLS-TP equipment supports Ethernet rmp and mp2mp connections
(referred to as HVPLS). To monitor those rmp and mp2mp connections, MPLS-TP
equipment must support Y.1731 Ethernet OAM. These Ethernet rmp and mp2mp
connections in MPLS-TP networks have to be managed, its Y.1731 Ethernet OAM
has to be configured and Y.1731 OAM measurement results have to be
presented. draft-bhh-mpls-tp-oam-y1731 ensures that there is common OAM (and
OAM management) in MPLS-TP transport networks. I.e. the same OAM is used for
all types of connections (p2p, p2mp, rmp and mp2mp PW, LSP and
Ethernet/HVPLS connections). This reduces operational complexities.
 
Regards,
Maarten
PS. MPLS-TP OAM may also be deployed in non-transport networks, i.e. in
IP/MPLS networks in which IP and MPLS-TP are combined (instead of Ethernet
and MPLS-TP). In such non-transport networks, MPLS-TP OAM based on IP would
be the natural choice.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: woensdag 19 mei 2010 21:20
To: ext Greg Mirsky; Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] OAM tools in MPLS-TP (was: RE: Concerns Re: poll on
making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document)

Hi,

I am not sure what people mean by Y.1731. Is it the frame format that they
refer to or is it the functionality? 

For the frame format, we already discussed it many times in the past and we
can restart it again - personally see a lot of disadvantages in doing so and
I can re-explain ( in another context of discussion). In any case it will
not be the same as in Ethernet, and even if it is, many of the information
will not be used. 

But I do not see why one should care about frame format, but they should
care of functionality and operational experience. 

We have requirements for OAM in MPLS-TP and we should provide a solution
that applies to the requirements. 

I would like to see technical discussion on the proposed solution, in
relation to the requirements. 

Best regards,

Nurit

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 20 May 2010 09:14:28 +0200

FYI,

My reason for not supporting this draft to become WG draft
is that I consider it a new draft.
Even though it has now version 04 it is actually 00.
And I think is is very uncommon to move a 00 version
to WG without review on the list or presentation in
a meeting.

Between 02 and 04 all the editors have changed
Between 02 and 04 more than 300 lines have been changed
and these are not only editorial changes.

I am also wondering why it is still called BFD, this is
a new tool which behaves totally different.

Support for unidirectional CC/CV was removed, why?
I do not see any justification for the dependency between
a CC/CV mechanism and a protection topology.
MPLS-TP is CO-PS so the path is well known, and CV is
used to detect misconnections and not to discover a
path in an existing connection.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 May 2010 10:36:14 +0100

On 19/05/2010 22:30, Yang Yang wrote:
> Hello Nurit,
>
>     Instead to have many tools, why not use one tool to provide all 
> the functions? It will be nice if BFD could be extended for such use.
>
> Best Regards!
>    Yang
Yang

What is the advantage in compromising the design of one OAM tool by the 
constrains associated with the operational modes of another OAM tool?

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 20 May 2010 11:50:46 +0200

Sasha,
 
There are two types of addressing associated with any function and its OAM:
1) management plane address which allows a management system to interact
with the function
2) dataplane identifier which allows an OAM frame to be processed by the
intended function.

I assume that the addressing you refer to is the dataplane identification of
item 2 above. Correct?

If so, then Y.1731 OAM PDUs carry an EtherType, MEG Level and OpCode and
these three are used by MEP and MIP functions to determine if the function
has to extract the OAM frame. For all OAM frames except the LBM frame these
three identifiers are sufficient. The LBM frame needs a further
identification, and in Ethernet the DA field is carrying this additional
identifier. In MPLS-TP OAM the TTL expiry is providing this additional
identifier.

If you read section 4 of draft-bhh-mpls-tp-oam-y1731 then you will notice
that the "Link Trace" function in Y.1731 is not applicable in MPLS-TP.
Reason is that the Link Trace function traces the 'flow connectivity' within
a rmp or mp2mp connection. MPLS-TP does not support rmp or mp2mp
connections, so there is no need for a Link Trace function. In Ethernet the
ETH LTM/LTR OAM frames and ETH user frames have a common VLAN ID or PW label
(case of VPLS) to guarantee fate sharing OAM and user frames.

Regards,
Maarten

Sent: woensdag 19 mei 2010 22:50
To: Yang Yang

Yang,

I would be very happy to hear some details on adapting Y.1731 to the
following hard facts of life in the MPLS/MPLS-T data plane environment:

.         Addressing of MEPs and MIPs (groups and individual ones)

.         Fate-sharing of OAM and user traffic, esp. in the case of
linktrace messages.

Regards,

     Sasha