John/George:
Superficially this would appear to be a sensible view, but we have gotten to this point because for whatever reasons, on this subject the IETF has not served a portion of its community, both vendors and providers. This has been an ongoing issue.
I agree with Eric that '1' is a pragmatic view that acknowledges how we got to this point, and given the volume of past discussions on the subject, no other method of arbitration appears to be tractable. IMHO '1' will need refinement to become more workable.
If we can get to agreement that the OAM stuff should be done elsewhere, and bundle that with some agreement to cooperate on the key interoperablity issues (mainly IANA concerns), that should provide some form of workable framework. Ultimately it is the folks that buy this stuff that demand interoperability, and we will be answerable to them for all our sins. ;-)
Dave
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: Thursday, March 07, 2002 10:42 AM
> To: 'George Swallow'; Shahram Davari
> Cc: 'Scott Bradner'; ccamp@ops.ietf.org
> Subject: RE: MPLS OAM & the IETF
>
>
> George,
>
> A very sensible view.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Wednesday, March 06, 2002 9:26 AM
> To: Shahram Davari
> Cc: 'Scott Bradner'; ccamp@ops.ietf.org; swallow@cisco.com
> Subject: Re: MPLS OAM & the IETF
>
>
> > Could you please clarify option (1) a bit more? If this route is
> > taken, still cooperation is needed between ITU and IETF. For example
> > ITU may need MPLS signaling extensions. Also in some cases packet
> > processing may need to be aligned between ITU and IETF in order to
> > avoid conflicts. For example ITU may consider an MPLS
> path-trace that
> > uses TTL expiration, which requires a TTL expired MPLS packet to be
> > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL
> > expired packets to ICMP/GTTP module. There needs to be a
> coordination
> > between IETF and ITU in order to find a common method which could
> > determine whether a packet should be forwarded to OAM or ICMP/GTTP
> > module.
>
> It's precisely issues such as these that lead me to believe that it
> would be best if *only one* standards body owns a core technology.
> Certainly other bodies should be free to create applications, define
> extentions, and do implementation agreements. But when it come to
> something a central as the basic forwarding plane, one group alone
> should handle it.
>
> Allowing another body to redifine core functions WILL lead to
> interoperability problems.
>
> ...George
>
> ==================================================================
> George Swallow Cisco Systems (978) 497-8143
> 250 Apollo Drive
> Chelmsford, Ma 01824
>
>