Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

From: Ross Callon <[email-masked]>
Date: Tue, 18 Jan 2011 15:39:00 -0500

There are at least three questions here:

    - Do we want one solution for MPLS OAM, or two?

    - Once we make a decision, do we intend to work to make
      it happen, or to continue the argument indefinitely?

    - Do we want standards for the IETF TCP/IP/MPLS protocol suite
      to be done in one standards body, or independently in two 
      different groups with incompatible standards resulting?

Answering these in the reverse order:

It is a very bad idea to have two different standards bodies writing
incompatible standards for the same protocol. The best that we could
hope for in this case would be to severely slow down any attempt to 
produce standards, with a very real possibility of equipment being 
deployed that won't interwork, or that might interwork in disastrous 
ways (it is possible for entire networks to collapse).

There is a very long history in the IETF, as well as other standards
groups, of multiple groups of people coming into the standards effort
with different ideas with regard to what a standard should look like. 
We work to discuss those ideas and come to a rough consensus on a way 
forward. At some point we need to stop arguing the same points over and 
over again and get on with the productive task of actually writing 
workable standards. It is common for "pre-standards" solutions to be 
deployed in at least some networks. It is normal that most or usually 
all vendors involved have to change their products to fit the emerging 
standard, and normal for vendors and service providers to need to work 
together to migrate the deployed equipment to follow the standards. 
Every vendor has been in the situation where they need to update products 
to match the standards, that is just life. One outcome that has been 
followed on occasion is that we pick one standards track solution, publish 
that solution in standards track RFCs, and document one or more other 
additional solutions in informational RFCs with the statement that these 
were offered for consideration in the IETF deliberations that resulted in 
[reference the standard].
 
We have not seen any disagreement over the point that the various 
proposed OAM solutions could be enhanced to fulfill the requirements.
The primary justification for having two solutions to do the same thing
seems to be "we have already deployed this so you have to accept it". 
That argument has almost never won in any standards group that we have 
been involved in (and over the past 30+ years some of us have been 
involved in IEEE802, Internet Working Groups, ANSI, ISO, Gads, IETF, 
and at least a few CCITT and ITU-T meetings). There have been times over 
the past 25 years that the IETF has accepted two solutions for the same 
thing, and we (the entire IETF community) generally have lived to regret 
it. The basic summary of what happens is that both get deployed, and we 
are stuck with interoperability issues and with doing twice the necessary 
work essentially forever.

Ross, Loa, and George (as MPLS WG co-chairs)

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 18 Jan 2011 23:52:33 +0100

Hello Ross,

> There are at least three questions here:

Let me try to answer them

>      - Do we want one solution for MPLS OAM, or two?

I think we want one toolbox with a set of tools.
It may happen that there are tools that ook alike but may be
different in detail because they are used in a different context.

>        it happen, or to continue the argument indefinitely?

I we agree that there can be different contexts in which dedicated
tools from the toolbox can be used the opposition disappears.

>        different groups with incompatible standards resulting?

If we agree that there are different contexts, it should be
possible to have the context sensitive tools developped by the
experts in a particular context/area.

Currently I can identify two contexts:
-1- packet switched networks, the dedicated tools should behave
     similar to existing tools
-2- packet transport networks, the dedicated tools should behave
     similar to existing transport technologies.

Regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 18 Jan 2011 17:56:21 -0600

Hi Huub-

>      similar to existing transport technologies.

I doubt we'll ever get everyone to hold hands and agree and sing happy songs on this point, but let me ask anyways.  Why do we still need different tools for packet switched vs packet transport networks?  The two terms are so similar that it's not obvious on its face whether these two are actually any different any more, is it really worth all the hassle from a technical perspective?  And if that's true and was true all along, why did everyone agree to cooperate in the first place [JWT agreement], and agree that there should only be one solution [ref. Russ Housely's brief talk in Beijing]?

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Huub van Helvoort
> Sent: Tuesday, January 18, 2011 5:53 PM
> To: [email-masked]
> Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref
> 043.02]
> 
> Hello Ross,
> 
> You wrote:
> 
> It may happen that there are tools that ook alike but may be different in
> detail because they are used in a different context.
> 
> I we agree that there can be different contexts in which dedicated tools
> from the toolbox can be used the opposition disappears.
> 
> If we agree that there are different contexts, it should be possible to
> have the context sensitive tools developped by the experts in a particular
> context/area.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Wed, 19 Jan 2011 12:34:09 +0800

hi, Huub and Eric
 maybe i think it is good suggestion to have an unique tool for packet 
switched and transport network.
but in fact, in my thinking, now we can't find a unique tool and solution 
to fulfil PSN and PTN network requirement.
if we have alreadly find the unique solution and tool ,why do we have not 
an unique agreement and advice?
so we need to consider  which solution and tool will be more suitable for 
current PSN and PTN network requirement now.
don't wastely take too much time to other non-technologly question. or 
else , we can't solve the problem for ever.

thank you 
liu

"Eric Osborne (eosborne)" <[email-masked]> 
发件人:  [email-masked]
2011-01-19 07:56

收件人
"Huub van Helvoort" <[email-masked]>, <[email-masked]>
抄送

主题
Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hi Huub-

>      similar to existing transport technologies.

I doubt we'll ever get everyone to hold hands and agree and sing happy 
songs on this point, but let me ask anyways.  Why do we still need 
different tools for packet switched vs packet transport networks?  The two 
terms are so similar that it's not obvious on its face whether these two 
are actually any different any more, is it really worth all the hassle 
from a technical perspective?  And if that's true and was true all along, 
why did everyone agree to cooperate in the first place [JWT agreement], 
and agree that there should only be one solution [ref. Russ Housely's 
brief talk in Beijing]?

eric

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Jan 2011 07:54:03 +0200

Huub, Eric, all
FWIW I concur with Eric. I would even go further and state that:

- IP/MPLS and MPLS-TP by design share the same data plane  (required in RFC 5654 and standardized in RFC 5960). 
AND
- The OAM tools in question are intended to detect and localize defects in this common data plane.

Hence the distinction between the two contexts proposed by Huub would not be applicable to  these two technologies 
when it comes to the OAM toolset - even if we agree that two different contexts exist.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eric Osborne (eosborne) [[email-masked]]
Sent: Wednesday, January 19, 2011 1:56 AM
To: Huub van Helvoort; [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref       043.02]

Hi Huub-

eric

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 Jan 2011 07:12:21 +0100

Hi Huub,
RFC 5860 specifies the requirements for MPLS-TP OAM and requires (among the rest) that the behavior and operational experience will be similar to those in transport networks. 
The solutions currently being defined (and I warmly recommend you to review the latest versions and comment) fully satisfy these and all the rest of the requirements. 
There is NO justification for additional solution! There is no justification to confuse the Industry, there is no justification to bloat operation and capital expenses and even to have bad impact on the end customer because of the former issues (confusion, cost, etc.). 
I object to define two standard solutions for the same problem. 
The toolset includes different tools, each providing a different functionality (such as CV, packet loss, etc.). we do not have two tools doing the same thing.
The main concern I have with your approach, is that the advocators of the alternative solution were never ready to get into technical discussion and discuss it tool by tool, to show what functionality the alternative proposal proposes that the solution being defined does not provide, and why such a gap (if exist) cannot be resolved in the context of the solution being defined. 
The words you use below look to me simply as buzzwords.... 
I am also extremely concerned from the time all this endless discussion take....we could use the time much more effectively if we use it to review the WG documents, comment and make sure it appropriately satisfy the requirements...and progress the documents fast to satisfy the urgent requirement for the tools. 
So I want to warmly recommend the experts to review the documents and provide productive comments, and ensure that we have a single solution that satisfy all the requirements and fits all deployment scenarios. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, January 19, 2011 12:53 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hello Ross,

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 19 Jan 2011 08:00:43 +0100

Hello Eric,

You replied:

> I doubt we'll ever get everyone to hold hands and agree and sing
 > happy songs on this point, but let me ask anyways.  Why do we still
 > need different tools for packet switched vs packet transport networks?
 > The two terms are so similar that it's not obvious on its face whether
 > these two are actually any different any more, is it really worth all
 > the hassle from a technical perspective?

If you look at the terms they look similar, but packet transport differs
from packet switching in the way packets are transported. In packet
transport the objective is to transport packets independend of the
technology, so it is important that the OAM for packet transport is
the same in all transport technologies.

> And if that's true and was true all along, why did everyone agree
 > to cooperate in the first place [JWT agreement], and agree that there
 > should only be one solution [ref. Russ Housely's brief talk in Beijing]?

Just out of curiosity:
When and where was this agreed?
Who was present when this agreement was reached?

Regards, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Jan 2011 09:03:00 +0200

Huub,
You've said:

      In packet transport the objective is to transport packets independent of the technology.

If you mean that the objective is to transport packets independent of the data plane technology,
I'd say that such an objective is IMHO unrealistic.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Huub van Helvoort [[email-masked]]
Sent: Wednesday, January 19, 2011 9:00 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hello Eric,

Just out of curiosity:

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 Jan 2011 08:26:29 +0100

Huub,

You say:

"If you look at the terms they look similar, but packet transport differs from packet switching in the way packets are transported. In packet transport the objective is to transport packets independend of the technology, so it is important that the OAM for packet transport is the same in all transport technologies."

Nurit: Do you say that the forwarding of MPLS packets is different in both proposals? Do you say that in transport networks the forwarding of the packets is independent of the MPLS forwarding mechanisms? Is there a magic way to transmit the packets without relying on the technology? 

Also, I do not understand the logic between the requirement you put "to transport packets independend of the technology" and the conclusion that "it is important that the OAM for packet transport is the same in all transport technologies"

The requirement is to have similar functionality and operational experience as in other transport network…this does not mean that it has to be implemented the same way….or that there is a need to use the same frame format….so please stop confusing the Industry! The way it looks and feel does not dictate how it is implemented and which frame formats are used.

In MPLS-TP the forwarding is based on the MPLS forwarding construct and the OAM packets may be sent inband over G-Ach…..

Your arguments make me very much concerned now…and the need to define a technology in the place where the design authority exists seems to be stronger than ever!

BR,

Nnurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, January 19, 2011 9:01 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hello Eric,

Just out of curiosity:

Regards, Huub.

 

-- 

                          我爱外点一七三一

mpls mailing list

[email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 Jan 2011 08:31:50 +0100

Huub,

You say:

Nurit: Do you say that the forwarding of packets is different in both proposals? Do you say that in transport networks the forwarding of the packets is independent of the MPLS forwarding mechanisms? Is there a magic way to transmit the packets without relying on the technology? 

BR,

Nnurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, January 19, 2011 9:01 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hello Eric,

Just out of curiosity:

Regards, Huub.

 

-- 

                          我爱外点一七三一

mpls mailing list

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 19 Jan 2011 08:55:41 +0100

Hi Sasha,

>From a management point of view it is realistic, you manage the transport of
Characteristic Information from ingress to egress.

Regards, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Jan 2011 11:10:23 +0200

Huub,
Sorry to say that, but I've failed to understand your response and its linkage to the original topic of the discussion
(could be because I am exceptionally dumb today:-).

Or could it be that you've misunderstood my statement?

Please bear me to remind you about at least three well-known differences between Ethernet and MPLS/MPLS-TP data planes that, IMHO, directly affect the data plane OAM toolsets.

1. Layering/nesting :
- There is effectively no layering/nesting in the Ethernet data plane (let's put aside PB/PBB for the moment). Hence
  the need for encoding the nesting levels in the IEEE 802.1ag/Y.1731 messages and explicit specification of treatment
  of these messages when received by a MEP at a different level
- In MPLS/MPLS-TP layering/nesting is mapped to the existing data plane construct (the label stack). As a consequence,
  there is no need to encode the level in the body of the OAM messages, because the mismatch does not occur.

2. Addressing:
  - Ethernet uses globally unique unicast MAC addresses as the identifiers of MEPs and MIPs. And these addresses are
    inherently encoded in the OAM messages generated by those, as Source MAC addresses, and are interpreted by the 
    Ethernet data plane in the MAC learning process. By implication, MIP address is also globally unique.
  - There is no global addressing at all in the MPLS/MPLS-TP data plane. Identification of the source MEPs/MIPs
    in the OAM messages they generate is an artifact that does not affect the data plane in any way. 
    And MIP "addresses" are based on TTL, so that a change in the number of hops between a MEP and a MIP would
    affect addressing.  

3. Reverse Paths
   - With Ethernet, if a MEP sends a message to another MEP/MIP, the MAC learning process creates the reverse path 
     in the data plane (and this path will be co-routed with the actual path traversed by the original message).
     (Incidentally, MAC learning may also produce problems, and this is why one of the most important OAM tools in
     Ethernet networks is flush of the FIB. It is not part of any standard, but it is there nevertheless.)
   - In MPLS/MPLS-TP, reverse paths must be created by the control or management plane and may be co-routed or not.
     (This is why so many MPLS-TP OAM documents contain the caveats "MUST applicable to co-routed bi-directional P2P    
     LSP", or "MAY be applicable to a unidirectional P2P/P2MP LSP if the reverse path exists").
     And AFAIK, there is no analog of the LIB flush in MPLS/MPLS-TP.

I am not sure if a human being operating packet transport networks can ignore these difference and still operate both these networks effectively. But I am pretty sure that the OAM protocols used for detection and localization of data plane defects could not ignore these differences and remain useful.

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Wednesday, January 19, 2011 9:56 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hi Sasha,

Regards, Huub.

> _______________________________________

---

From: <[email-masked]>
Date: Wed, 19 Jan 2011 09:53:00 +0000

Eric Osborne wrote 18 January 2011 23:56:

> I doubt we'll ever get everyone to hold hands and agree and 
> sing happy songs on this point, but let me ask anyways.  Why 
> do we still need different tools for packet switched vs 
> packet transport networks?  The two terms are so similar that 
> it's not obvious on its face whether these two are actually 
> any different any more, is it really worth all the hassle 
> from a technical perspective?  And if that's true and was 
> true all along, why did everyone agree to cooperate in the 
> first place [JWT agreement], and agree that there should only 
> be one solution [ref. Russ Housely's brief talk in Beijing]?
> 
Hi Eric,

The co-cs mode and co-ps mode are different in many ways...this also plays through to OAM, eg AIS is a must-have for the co-cs mode but it is an unnecessary function if included in the co-ps mode.   The work on GMPLS also shows that there are important differences...and note we don't have sublayering or PWs here, and the notion of a 'common CP' is largely dead.  So we can't have identical solutions.

If one really wants the co-ps mode to act as a transport network however (which I thought was the main driver for MPLS-TP) then it should have specific architectural behaviours it has to meet (folks can then compromise these if they so choose, but the technology itself must be capable of delivering them else it cannot claim to be a transport network).  Note - many important customers usually demand transparency of their transport services.  A transport network also should be able to drive an EM wave on metallic/optical/radio section media.....

Transparency is THE major service a transport network must be able to provide.  I'll spare going over the details of what this means, but here one can simply note that one of the consequences of this is that a properly designed co-ps mode transport network would not have sublayering nor PWs.

>From the minimalist defect-handling OAM perspective we need the CV and BDI messages where the CV message carries a proper source address of the layer network it is being used in.  We do not need AIS nor TCM.  One can select CV and BDI messages from Y.1731 and ignore the ones that are not required.

regards, Neil
<snipped to end>

---

From: <[email-masked]>
Date: Wed, 19 Jan 2011 10:22:24 +0000

I share your concerns Nurit.  One of the things that was clear to me a long time ago was the misguided view that making the OAM the same in MPLS and Ethernet would somehow 'make them the same' and allow their interworking as peers.....nothing could be more wrong!  One would need full alignment of all aspects of the DP and CP to achieve this....including the DP message/file/stream end-system application adaptation functions...which of course don't exist as neither MPLS nor Ethernet is a TOS layer network.  And if one properly understands all the consequences of this observation it tells one that providing NNIs in (or worse between) these technologies is an unnecessary cost.

regards Neil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 19 January 2011 07:26
To: ext Huub van Helvoort; [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Huub,

You say:

BR,

Nnurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, January 19, 2011 9:01 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hello Eric,

Just out of curiosity:

Regards, Huub.

--

                          我爱外点一七三一

mpls mailing list

[email-masked]

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 19 Jan 2011 05:12:59 -0600

Inline with EO#

...

>  > happy songs on this point, but let me ask anyways.  Why do we still  >
> > these two are actually any different any more, is it really worth all  >
> technology, so it is important that the OAM for packet transport is the
> same in all transport technologies.

EO#  I don't see how you could possibly have a protocol that was independent of *any* technology.  And I think we've done pretty well with packet networks without consistent OAM between IP/MPLS and the underlying transport.  So personally I don't agree with your contention that OAM must be the same.

But I'll stipulate for a second that you're correct in that this ubiquity of OAM is now important.  *Why* is it important?  Is it only important for OAM?  What about signaling?  Protection?  Management?  How much can two different things share before they're no longer different?

> Who was present when this agreement was reached?

EO#  The minutes are here:
http://tools.ietf.org/wg/mpls/minutes?item=minutes79.html

and it's been discussed on this list as well, as I'm sure you know.  But put that aside - if this agreement was never reached, shouldn't the "two technologies, two protocols" approach have been spelled out from day one?  I refer you to rfc5317, which contains phrases like "jointly agree to work together" and nowhere contains the idea that two bodies agree to work together to invent two separate and incompatible things.

eric

> >> If we agree that there are different contexts, it should be possible
> >> to have the context sensitive tools developped by the experts in a
> >> particular context/area.
> >>

---

From: David Allan I <[email-masked]>
Date: Wed, 19 Jan 2011 10:05:23 -0500

Hi Neil:

You have wild agreement from this end.

The DP hierarchical models are sufficiently different to suggest that the only "practical" interworking model is overlay. Somthing that works fine today. A peer interworking scenario would be a horrible mistake to actually aspire to!

my 2 cents
BR
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 19, 2011 2:22 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

regards Neil

Huub,

You say:

BR,

Nnurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, January 19, 2011 9:01 AM
To: [email-masked]
Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02]

Hello Eric,

Just out of curiosity:

Regards, Huub.

--

                          我爱外点一七三一

mpls mailing list

[email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 19 Jan 2011 08:08:59 -0800

Snipped, comments inline

Sent from my iPhone

> technology

JD:  I get the sense that you're not very familiar with the way that packet switching, and in particular IP and MPLS, work.  In these networks, the switching of packets is completely independent of the underlying L1/L2 technology of the links between packet switching nodes.  

> , so it is important that the OAM for packet transport is

JD:  This sounds like a quote from Professor Irwin Corey.  It is important that the MPLS network has an OAM capability that is independent of the OAM capabilities of the underlying L1/L2 technologies.  It is not important that the MPLS network uses the same OAM protocols as a particular L1/L2 technology, simply because there are so many different ones.  I think Neil Harrison would call this client/server 101.

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 19 Jan 2011 13:37:57 -0500

> JD:  I get the sense that you're not very familiar with the way that packet switching, and in particular IP and MPLS, work.  In these networks, the switching of packets is completely independent of…

	To add to the point you made above, that independence is done *intentionally* and for very good reasons.

> JD:  This sounds like a quote from Professor Irwin Corey.  It is important that the MPLS network has an OAM capability that is independent of the OAM capabilities of the underlying L1/L2 technologi…

	As I recall, the original intent of the requirements was to have the same operational "look and feel" for operators familiar with optical transport technologies. The intent was that operational activities such as provisioning and troubleshooting be designed in such a way as to be familiar to what operators were used to.  I don't think this translates into requiring that identical technologies are used.  And as you say, it it not a good idea to have them intimately linked for the same good network layering design principles.

	--Tom