Subject: [mpls-tp] Status of draft-ietf-mpls-tp-ach-tlv

From: [email-masked]
Date: Wed, 10 Nov 2010 20:54:48 -0500

I am confused by the statement that we need to discuss the status of 
draft-ietf-mpls-tp-ach-tlv on the list.

During discussion late August/early September in the context of the RFC vs 
ITU Recommendations dependancy table the following statement was made:

1. draft-ietf-mpls-tp-ach-tlv
    This draft has expired and we do not intend to keep it
    updated, instead definitions of TLVs for the associated
    channel will be defined in the appropriate specification.
    It is also not referenced by G.7712

Therefore the draft was removed from the dependance table.

Has the status changed?

Regards,

Malcolm

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 11 Nov 2010 02:08:36 +0000

Malcolm

Note 1 below accords with my recollection of the situation.

There are some drafts that seem to have incorporated the ACH TLV, but my 
understanding accords with the note below. The h/w designers (in a 
number of companies) have said that they would find them difficult and 
thus ACH TLV should be dropped from those drafts.

- Stewart

On 11/11/2010 01:54, [email-masked] wrote:
> draft-ietf-mpls-tp-ach-tlvon the list.
>
> During discussion late August/early September in the context of the 
> RFC vs ITU Recommendations dependancy table the following statement 
> was made:
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2010 02:34:37 -0000

I think you have captured the key text and status of the document although I am
sure the chairs will want to comment.
 
My hearing was that you were asking about one draft during a discussion of a
different draft, and the chairs said please discuss this on the list.
 
Actually, this is exactly what you have done :-)
 
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 11 November 2010 01:55
To: [email-masked]
Subject: [mpls-tp] Status of draft-ietf-mpls-tp-ach-tlv

During discussion late August/early September in the context of the RFC vs ITU
Recommendations dependancy table the following statement was made: 

Has the status changed? 

Regards, 

Malcolm

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2010 02:40:25 -0000

Oh, and the base construct for ACH TLVs is provided in RFC 5586.
Retiring the ACH TLV I-D simply reflected that we could not find any "generic"
TLVs to define.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stewart Bryant
> Sent: 11 November 2010 02:09
> To: [email-masked]
> Subject: Re: [mpls-tp] Status of draft-ietf-mpls-tp-ach-tlv
> 
> Malcolm
>

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 03:45:24 +0100

This mail is to raise the question for clarification I was not allowed to raise during the MPLS WG meeting this morning.

My understanding of the answer made by Dave to the question/comment of Alessandro, is that given the fact that there are IP routers in the field who cannot support hardware-based pro-active CC/CV, the whole PTN industry has to suffer with a solution pro-active CC/CV that has lower performance and higher complexity (i.e., cost) than necessary.

Italo

---

From: David Allan I <[email-masked]>
Date: Wed, 10 Nov 2010 22:16:40 -0500

Hi Italo:

I prefer to think of it in somewhat less negative terms...

I've actually been on the page of eliminating CC since Hiroshima as it struck me as a rather useless option, but the requirement for a distinct CC transaction/functionality seems to be somthing that originates with the JWT therefore is viewed as sacrosanct by some. Legacy BFD with an IP header has always been a CV equivalent as source information was already encoded in the packet's IP header and processed in implementations.

So I'm in favor of a means of providing CV functionality in a form that satisfies the broader community and in a form that addresses concerns of those who have latched onto CC because of the additional processing CV requires. This does seem to fit the bill, and provides for a graceful evolution to allow both retrofitting of existing equipment and eventual deprecation of CC operation. An alternative suggested today would be to always send CV source MEP information but have a recevier that cannot keep up randomly sample it, my concern being that this would complicate both entry and exit criteria from a misconnectivity defect.

Why this can be said to result in lower performance and cost than necessary is not clear to me. Yes it does add a single logical "if" operation to the message processing but I think the overall benefits justify the line of code, or couple of extra gates, given we've already taken the regressive step of having CC only functionality. 

And with respect to cost, say this with a straight face to the folks that have to fork lift deployed equipment when that is the only alternative presented to them.

My 2 cents
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: Wednesday, November 10, 2010 9:45 PM
To: [email-masked]
Cc: Ad hoc MPLS-TP
Subject: [mpls-tp] My question for clarification on draft-ietf-mpls-tp-cc-cv-rdhai-02

Italo

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 11 Nov 2010 07:59:20 +0000

Italo,

> My understanding of the answer made by Dave to the question/comment of Alessandro, is that given the fact that there are IP routers in the field who cannot support hardware-based pro-active CC/CV,…

Dave responded to the specifics and while I do not view this situation in as negative terms as you do this is one the consequences of design by committee (i.e. standards), however experience shows us that while nothing is perfect the industry prefers non-perfection (what you describe as the PTN industry "suffering") to proprietary solutions.

One of the largest challenges I continuously faced when I worked at an operator was network upgrades. Fork lift upgrades are very difficult to execute in practice when there is any significant deployment, it's not only expensive in terms of capex but it is inevitable that there will be at least a few niggles (we're all human after all) that means a certain level of customer churn will also occur.

If an operator chooses to deploy pre-standards implementations (which is often the case for very good business/market reasons) then they have to accept and plan for the risk that goes with that (caveat emptor). I think telling an operator who has deployed a standardised solution that they must perform a fork lift upgrade to "evolve" to the latest standards is not the right approach unless it really is completely unavoidable (which is not true in this case).

Ben

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 09:39:48 +0100

Ben,

I think you are misinterpreting my meaning. If you read, section 1 of draft-bhh:

http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-06

You can find the following text:

"
   This document does not deprecate existing MPLS and PW OAM mechanisms
   nor preclude definition of other MPLS-TP OAM tools.
"

As a consequence, I do not see any need for a fork lift upgrades imposed to an operator who has already deployed a network based on existing BFD. He can continue to live with its own BFD installed base.

Italo

> -----Messaggio originale-----
> Da: Ben Niven-Jenkins [mailto:[email-masked]]
> Inviato: giovedì 11 novembre 2010 15.59
> A: BUSI, ITALO (ITALO)
> Cc: [email-masked]
> Oggetto: Re: [mpls-tp] My question for clarification on draft-ietf-mpls-
> tp-cc-cv-rdhai-02
> 
> Italo,
> 
> > This mail is to raise the question for clarification I was not allowed
> to raise during the MPLS WG meeting this morning.
> >
> > My understanding of the answer made by Dave to the question/comment of
> Alessandro, is that given the fact that there are IP routers in the field
> who cannot support hardware-based pro-active CC/CV, the whole PTN industry
> has to suffer with a solution pro-active CC/CV that has lower performance
> and higher complexity (i.e., cost) than necessary.
> 
> Dave responded to the specifics and while I do not view this situation in
> as negative terms as you do this is one the consequences of design by
> committee (i.e. standards), however experience shows us that while nothing
> is perfect the industry prefers non-perfection (what you describe as the
> PTN industry "suffering") to proprietary solutions.
> 
> One of the largest challenges I continuously faced when I worked at an
> operator was network upgrades. Fork lift upgrades are very difficult to
> execute in practice when there is any significant deployment, it's not
> only expensive in terms of capex but it is inevitable that there will be
> at least a few niggles (we're all human after all) that means a certain
> level of customer churn will also occur.
> 
> If an operator chooses to deploy pre-standards implementations (which is
> often the case for very good business/market reasons) then they have to
> accept and plan for the risk that goes with that (caveat emptor). I think
> telling an operator who has deployed a standardised solution that they
> must perform a fork lift upgrade to "evolve" to the latest standards is
> not the right approach unless it really is completely unavoidable (which
> is not true in this case).
> 
> Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 11 Nov 2010 16:48:10 +0800

> As a consequence, I do not see any need for a fork lift upgrades imposed to an operator who has already deployed a network based on existing BFD. He can continue to live with its own BFD installed…

	While perhaps not a "forklift" upgrade, what you describe can result in a significant charge to the OSS, so Ben's point of added expense is indeed plausible.

	--Tom

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 10:06:01 +0100

Tom,

What type of "significant charge to the OSS" are you thinking of?

You have a deployed IP/MPLS network with BFD.

You upgrade it to support draft-bhh. You keep Y.1731 CCM disabled because BFD is already running and you are very happy with it.

You just enable the additional features (e.g., Y.1731 PM) that you need.

Where is the problem?

Thanks, Italo

> Da: Thomas Nadeau [mailto:[email-masked]]
> Inviato: giovedì 11 novembre 2010 16.48
> A: BUSI, ITALO (ITALO)
> Cc: Ben Niven-Jenkins; [email-masked]
> Oggetto: Re: [mpls-tp] R: My question for clarification on draft-ietf-
> mpls-tp-cc-cv-rdhai-02
> 
> 
> > As a consequence, I do not see any need for a fork lift upgrades imposed
> to an operator who has already deployed a network based on existing BFD.
> He can continue to live with its own BFD installed base.
> 
> 	While perhaps not a "forklift" upgrade, what you describe can result
> in a significant charge to the OSS, so Ben's point of added expense is
> indeed plausible.
> 
> 	--Tom
> 
> >
> > Italo
> >

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 11 Nov 2010 10:06:57 +0100

Italo,
While it is nice to see that you do not deprecate existing solution, and do not preclude the definition of other MPLS-TP OAM tools...
I wonder if you are proposing defining multiple solutions for the same problem in MPLS-TP!
Do you want to define multiple solutions that may not interoperate, which can result in confusion, bloat capital and operational expenses, and sometimes even have negative impact on customers' experiences?
I object to this, and whatever the solution is, there must be a single solution!
I would like to refer you to Russ' introduction this morning. He said (From the MPLS mtg Jabber log): "the goal is to have a single interoperable Internet.  We've failed once or twice.  But re this OAM stuff we've decided to have one solution". This must be our design directive.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext BUSI, ITALO (ITALO)
Sent: Thursday, November 11, 2010 10:40 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: [mpls-tp] R: My question for clarification on draft-ietf-mpls-tp-cc-cv-rdhai-02

Ben,

"

Italo

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 10:12:31 +0100

Nurit,

I am proposing one solution for one specific problem: OAM for MPLS-TP in PTN applications and this is based on draft-bhh.

Italo

> Da: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> [mailto:[email-masked]]
> Inviato: giovedì 11 novembre 2010 17.07
> A: BUSI, ITALO (ITALO); Ben Niven-Jenkins
> Cc: [email-masked]
> Oggetto: RE: [mpls-tp] R: My question for clarification on draft-ietf-
> mpls-tp-cc-cv-rdhai-02
> 
> Italo,
> While it is nice to see that you do not deprecate existing solution, and
> do not preclude the definition of other MPLS-TP OAM tools...
> Do you want to define multiple solutions that may not interoperate, which
> can result in confusion, bloat capital and operational expenses, and
> sometimes even have negative impact on customers' experiences?
> I would like to refer you to Russ' introduction this morning. He said
> (From the MPLS mtg Jabber log): "the goal is to have a single
> interoperable Internet.  We've failed once or twice.  But re this OAM
> stuff we've decided to have one solution". This must be our design
> directive.
> Best regards,
> Nurit
> 
> Of ext BUSI, ITALO (ITALO)

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 11 Nov 2010 10:18:25 +0100

Hi,
We have one MPLS(-TP) technology! We do not have a technology per application!
In order to be productive, I would like to encourage you to review the IETF documents and indicate what your technical concerns are! 
Any technical comment that can help to enhance the solution, is very much appreciated. 
Best regards,
Nurit
 
-----Original Message-----
From: ext BUSI, ITALO (ITALO) [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 11:13 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Ben Niven-Jenkins
Cc: [email-masked]
Subject: R: [mpls-tp] R: My question for clarification on draft-ietf-mpls-tp-cc-cv-rdhai-02

Nurit,

Italo

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 11:02:37 +0000

The other major point not mentioned here by Ben is 'don't produce bad architectural stds in the 1st place...esp ones that have layering violations and unnecessary inter-layer/component functional dependencies'.....I'll resist providing a few choice examples of this ;-)

regards, Neil 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: 11 November 2010 07:59
> To: BUSI, ITALO (ITALO)
> Cc: [email-masked]
> Subject: Re: [mpls-tp] My question for clarification on 
> draft-ietf-mpls-tp-cc-cv-rdhai-02
> 
> Italo,
> 
> > This mail is to raise the question for clarification I was 
> not allowed to raise during the MPLS WG meeting this morning.
> > 
> > My understanding of the answer made by Dave to the 
> question/comment of Alessandro, is that given the fact that 
> there are IP routers in the field who cannot support 
> hardware-based pro-active CC/CV, the whole PTN industry has 
> to suffer with a solution pro-active CC/CV that has lower 
> performance and higher complexity (i.e., cost) than necessary.
> 
> Dave responded to the specifics and while I do not view this 
> situation in as negative terms as you do this is one the 
> consequences of design by committee (i.e. standards), however 
> experience shows us that while nothing is perfect the 
> industry prefers non-perfection (what you describe as the PTN 
> industry "suffering") to proprietary solutions.
> 
> One of the largest challenges I continuously faced when I 
> worked at an operator was network upgrades. Fork lift 
> upgrades are very difficult to execute in practice when there 
> is any significant deployment, it's not only expensive in 
> terms of capex but it is inevitable that there will be at 
> least a few niggles (we're all human after all) that means a 
> certain level of customer churn will also occur.
> 
> If an operator chooses to deploy pre-standards 
> implementations (which is often the case for very good 
> business/market reasons) then they have to accept and plan 
> for the risk that goes with that (caveat emptor). I think 
> telling an operator who has deployed a standardised solution 
> that they must perform a fork lift upgrade to "evolve" to the 
> latest standards is not the right approach unless it really 
> is completely unavoidable (which is not true in this case).
> 
> Ben
>

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 11:26:32 +0000

Nurit....be careful...MPLS is anything but singular!  However, there is a key point in what you note below and this is all about having consistent CI (Characteristic Information) of a layer network.  This becomes acutely important in co-cs and (esp) co-ps mode layer networks because one can take several short-cuts on the labelling of child traffic units (this is more than the forwarding label) because (i) the parent connection carries the removed information and (ii) a connection is a constraining construct under defect-free conditions to its child traffic units.  However, under misconnectivity the connection is no longer a constraining construct and this is why it is vital that wherever the child traffic unit ends-up its OH field (part of its CI) can be correctly parsed/interpreted.  Ergo the requirement for consistent OAM at all trail term pts in a layer network.

However, I should point out that MPLS and MPLS-TP do not have consistent CI, and the carry-over of sublayering and PWs into MPLS-TP are not great ideas for a technology that is supposed to be providing a transparent transport network (they don't appear in GMPLS...I wonder why ;-))....I could add other examples.....

regards, Neil

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 11 November 2010 09:07
> To: ext BUSI, ITALO (ITALO); Ben Niven-Jenkins
> Cc: [email-masked]
> Subject: Re: [mpls-tp] R: My question for clarification on 
> While it is nice to see that you do not deprecate existing 
> solution, and do not preclude the definition of other MPLS-TP 
> OAM tools...
> Do you want to define multiple solutions that may not 
> interoperate, which can result in confusion, bloat capital 
> and operational expenses, and sometimes even have negative 
> impact on customers' experiences?
> I would like to refer you to Russ' introduction this morning. 
> He said (From the MPLS mtg Jabber log): "the goal is to have 
> a single interoperable Internet.  We've failed once or twice. 
>  But re this OAM stuff we've decided to have one solution". 
> This must be our design directive.
> Best regards,
> Nurit
> 
> [mailto:[email-masked]] On Behalf Of ext BUSI, ITALO (ITALO)
> As a consequence, I do not see any need for a fork lift 
> upgrades imposed to an operator who has already deployed a 
> network based on existing BFD. He can continue to live with 
> its own BFD installed base.
> 
> Italo
> 
> question/comment 
> > > of
> > Alessandro, is that given the fact that there are IP routers in the 
> > field who cannot support hardware-based pro-active CC/CV, the whole 
> > PTN industry has to suffer with a solution pro-active CC/CV 
> that has 
> > lower performance and higher complexity (i.e., cost) than necessary.
> > 
> > Dave responded to the specifics and while I do not view 
> this situation 
> > in as negative terms as you do this is one the consequences 
> of design 
> > by committee (i.e. standards), however experience shows us 
> that while 
> > nothing is perfect the industry prefers non-perfection (what you 
> > describe as the PTN industry "suffering") to proprietary solutions.
> > 
> worked at an 
> > operator was network upgrades. Fork lift upgrades are very 
> difficult 
> > to execute in practice when there is any significant 
> deployment, it's 
> > not only expensive in terms of capex but it is inevitable 
> that there 
> > will be at least a few niggles (we're all human after all) 
> that means 
> > a certain level of customer churn will also occur.
> > 
> implementations (which 
> > is often the case for very good business/market reasons) then they 
> > have to accept and plan for the risk that goes with that (caveat 
> > emptor). I think telling an operator who has deployed a 
> standardised 
> > solution that they must perform a fork lift upgrade to 
> "evolve" to the 
> > latest standards is not the right approach unless it really is 
> > completely unavoidable (which is not true in this case).
> > 
> > Ben
>