Subject: [Mpls-interop] Notes from MEAD CC 14-04-2009

From: Huub van Helvoort <[email-masked]>
Date: Wed, 15 Apr 2009 12:57:33 +0200

All,

Here are the notes from the MEAD team CC 14-03-2009:
(thanks to Italo and Scott for sharing their notes).
[present: Malcolm, Loa, Dave, Stuart, Scott, Italo,
Deborah, Julien, Huub, Adrian, Tom, ...]

-------- draft-ietf-mpls-tp-requirements-06 --------

The commenters will indicate ASAP which comments/questions
for clarification are mainly "editorial".
Major technical changes will be postponed, and may require
an extension later.

-------- OAM tools --------

Based on the number of proposals for OAM tools and the
difficulty to discuss them in a CC or by email is was
proposed to discuss them face-to-face during the ITU-T
meeting in Sophia Antipolis.

Loa and Malcolm will further discuss this option offline.

The scope this work: review the available drafts and determine
how to progress this work in the MEAD team to define the
solutions.

-------- OAM solutions --------

To progress the work the following statements were made:

Discussion regarding use of BFD:
- use baseline BFD and extend it to meet transport requirements
- use BFD for CC and define other tools for missing functinalities

It was stated that it is important to keep BFD part of MPLS-TP
specification

It was highlighted that the JWT slides also mention Y.1731

The use of Y.1731 PDUs was discussed/clarified:
- it does not deprecate anything, so there is no violation of
   the JWT agreement to allow usage of BFD for CC
- it is only reusing the Y.1731 OAM PDUs and not Ethernet-specific
   (cl-ps) functionality
- it relies upon JWT and OAM framework capabilities for TCM (using
   label stacking) and MIP (TTL expiry)

It was also stated that we should ensure that we have looked at all
the existing work.  So, one idea would be to summarize the standards
(BFD, Y.1731, Y.1711, ...) and provide a comparison of the terminology
to get everyone on the same page.

It is required to make a clear distinction between OAM functions
and OAM configuration functions

-------- Agreements --------

- the OAM protocols will run within the ACH
- define a list of required/essential OAM functions

-------- Not agreed yet --------

whether the OAM functions will be based on extensions to
BFD or on Y.1731 PDUs

-------- Next steps --------

- agree on which functions are actually needed
- determine if existing tools can be used/extended
- agree on which functions can go together (piggyback) to
   allow the support of multiple functions in the same PDU
- determine the encoding of the functions

Regards, Huub.

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

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 15 Apr 2009 14:54:46 +0200

> Deborah, Julien, Huub, Adrian, Tom, ...]

and of course: George, Luyuan, Kam, ...

Regards, Huub.

---

From: Sami Boutros <[email-masked]>
Date: Wed, 15 Apr 2009 06:42:36 -0700

For OAM solutions there are already drafts not based on BFD extensions
nor based on Y.1731 OAM PDU's.
And this was an option that was agreed to consider in the meeting too.

Thanks,

Sami
At 03:57 AM 4/15/2009, Huub van Helvoort wrote:
>_______________________________________________
>Mpls-interop mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 15 Apr 2009 16:54:50 -0700

Please see inline:

<snipped>

> It was stated that it is important to keep BFD part of MPLS-TP

The functionality provided by draft-ietf-bfd-mpls (BFD for MPLS) and RFC
4379 (LSP-Ping) must be part of MPLS-TP. Depending on the MPLS-TP
deployment environment this may or may not require carrying these
protocols in an ACH.

> to get everyone on the same page.

The guiding principle for the MPLS-TP work should be a) A single
solution for a particular OAM requirement and b) As much reuse of
existing MPLS OAM technology as possible.

> - the OAM protocols will run within the ACH

Depending on the environment in which MPLS-TP is
deployed OAM protocols may or may not run in an ACH. Hence the above
statement is not quite precise.

>From draft-ietf-mpls-tp-gach-gal-03

"RFC 4379 [4] and BFD-MPLS [3] define alert mechanisms that enable an
   MPLS LSR to identify and process MPLS OAM packets when these are
   encapsulated in an IP header.  These alert mechanisms are based, for
   example, on Time To Live (TTL) expiration and/or on the use of an IP
   destination address in the range of 127/8 or 0:0:0:0:0:FFFF:
   127.0.0.0/104, respectively for IPv4 and IPv6.  These mechanisms are
   the default mechanisms for identifying MPLS OAM packets when
   encapsulated in an IP header.  However it may not always be possible
   to use these mechanisms in some MPLS applications e.g., MPLS
   Transport Profile (MPLS-TP) [14], particularly when IP based
   demultiplexing cannot be used.  This document defines a mechanism
   that is RECOMMENDED for identifying and encapsulating MPLS OAM and
   other maintenance messages when IP based mechanisms such as those
   used in [4] and [3] are not available."

> whether the OAM functions will be based on extensions to

Or/and LSP-Ping.

> - determine the encoding of the functions

rahul

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Apr 2009 15:55:28 +0200

Loa,
I think this discussion should be taken when reviewing the OAM analysis
document. 
When can we start reviewing the OAM analysis?
Also Yaacov submitted important questions on the latest OAM requirements
draft which have impact on the OAM analysis draft. Unfortunately except
for Ben, we did not get any response. Authors, can you please respond?
Best regards,
Nurit 

P.S. Please note that LSP ping in not precluded in MPLS-TP. But as it
does not apply to the entire set of requirements, additional solution is
required for those environments that LSP Ping does not apply.  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Rahul Aggarwal
Sent: Thursday, April 16, 2009 2:55 AM
To: Huub van Helvoort
Cc: MEAD team
Subject: Re: [Mpls-interop] Notes from MEAD CC 14-04-2009

Please see inline:

<snipped>

Or/and LSP-Ping.

rahul

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Apr 2009 13:54:30 -0700

Rahul,

I think you are exactly right.

Thanks,

John
> From: Rahul Aggarwal [mailto:[email-masked]] 
> Sent: Wednesday, April 15, 2009 4:55 PM
> To: Huub van Helvoort
> Cc: MEAD team
> 4379 (LSP-Ping) must be part of MPLS-TP. Depending on the 
> MPLS-TP deployment environment this may or may not require 
> carrying these protocols in an ACH.
> 
> The guiding principle for the MPLS-TP work should be a) A 
> single solution for a particular OAM requirement and b) As 
> much reuse of existing MPLS OAM technology as possible.
> 
> > It is required to make a clear distinction between OAM 
> functions and 
> > OAM configuration functions
> >
> Depending on the environment in which MPLS-TP is deployed OAM 
> protocols may or may not run in an ACH. Hence the above 
> > whether the OAM functions will be based on extensions to BFD or on 
> > Y.1731 PDUs
> >
> 
> Or/and LSP-Ping.
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 17 Apr 2009 08:43:32 +0200

Nurit,

the OAM Analysis document is not one of the requested by the ITU-T
and is therefore low on the priority list for the review meetings.

Frankly I don't see much traction for that document.

The meeting lat Tuesday decided that a quicker way forward would
be get together for a white board session with the subset of people
that will be in Sophia for the SG15 interim meeting.

/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: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 17 Apr 2009 11:01:33 +0200

Hi Loa,
Thanks for your open communication.
The need for OAM analysis was identified at the beginning of the process
and was one of the MEAD team documents.
Frankely and recalling the original intention, I think that the
discussion on this document should lead us to the right decision on
which tools we need to extend or develop and which tolls can be used. I
will appreciate the reconsideration of discussing this document before
moving further to the solutions.
Best regards,
Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Friday, April 17, 2009 9:44 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Notes from MEAD CC 14-04-2009

Nurit,

the OAM Analysis document is not one of the requested by the ITU-T and
is therefore low on the priority list for the review meetings.

The meeting lat Tuesday decided that a quicker way forward would be get
together for a white board session with the subset of people that will
be in Sophia for the SG15 interim meeting.

/Loa

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> Loa,
> I think this discussion should be taken when reviewing the OAM 
> analysis document.
> Also Yaacov submitted important questions on the latest OAM 
> requirements draft which have impact on the OAM analysis draft. 
> Unfortunately except for Ben, we did not get any response. Authors,
can you please respond?
> does not apply to the entire set of requirements, additional solution 
> is required for those environments that LSP Ping does not apply.
> 
>> (BFD, Y.1731, Y.1711, ...) and provide a comparison of the 
>> terminology to get everyone on the same page.
>>
> 
>> It is required to make a clear distinction between OAM functions and 
> protocols may or may not run in an ACH. Hence the above statement is 
> not quite precise.
> 

-- 

Loa Andersson

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

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 24 Apr 2009 16:10:01 +0200

Hi all,
I couldn't attend this meeting but I wish to inform you that I'm working on the BFD extension and to
share this work with you; please consider it as a contribution to this community.

Regards,
Annamaria

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: mercoledì 15 aprile 2009 12.58
To: MEAD team
Subject: [Mpls-interop] Notes from MEAD CC 14-04-2009

All,

Here are the notes from the MEAD team CC 14-03-2009:
(thanks to Italo and Scott for sharing their notes).
[present: Malcolm, Loa, Dave, Stuart, Scott, Italo, Deborah, Julien, Huub, Adrian, Tom, ...]

-------- draft-ietf-mpls-tp-requirements-06 --------

The commenters will indicate ASAP which comments/questions for clarification are mainly "editorial".
Major technical changes will be postponed, and may require an extension later.

-------- OAM tools --------

Based on the number of proposals for OAM tools and the difficulty to discuss them in a CC or by email is was proposed to discuss them face-to-face during the ITU-T meeting in Sophia Antipolis.

The scope this work: review the available drafts and determine how to progress this work in the MEAD team to define the solutions.

-------- OAM solutions --------

It was stated that it is important to keep BFD part of MPLS-TP specification

It was also stated that we should ensure that we have looked at all the existing work.  So, one idea would be to summarize the standards (BFD, Y.1731, Y.1711, ...) and provide a comparison of the terminology to get everyone on the same page.

It is required to make a clear distinction between OAM functions and OAM configuration functions

-------- Not agreed yet --------

whether the OAM functions will be based on extensions to BFD or on Y.1731 PDUs

-------- Next steps --------

Regards, Huub.