Subject: RE: response to ITU-T SG13

From: "David Allan"<[email-masked]>
Date: Tue, 16 Apr 2002 10:30:32 -0400

Eric,

you're on the wrong tack. 

I am concerned that there are other hidden gotcha's out there with existing
implementations, and would like to see them all out ASAP. For example, IMHO
the discussion with Giles on hashing for load balancing was genuinely useful
and if followed up upon, we'll all be better off.  When it comes to
outlining concerns with the current state of implementation to SG13, it
would be nice if one comprehensive exchange settled concerns, rather than an
on-going parade.

In that regard I consider the discussion so far (w.r.t implementation) to
have made us all better. In fact, going back through some of the earlier
discussion, there were also concerns about hardware impacts of potentially
using y.1711 for protection switching that came up on the list during the
last IETF that are not reflected in this liaison, and probably should be in
the interest of complete transparency.

George noted, and I agree that merely adding an LSP attribute as to whether
fault detection is enabled will be fairly trivial and I'd observe that code
points have been given out for less and with less scrutiny. I consider the
impact on existing deployments much more interesting/important. 

It is not the reasonableness of the impact on implementation aspects of the
request I question. It is apparent arbitrary hurdle set by the some of the
more far-seeing aspects....

cheers
Dave 

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 10:06 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Loa Andersson; Scott Bradner; [email-masked]
> Subject: Re: response to ITU-T SG13 
> 
> 
> 
> David> I politely flagged  this one as I think  it is a bit 
> of  a stretch to
> David> ask the  ITU to comment on the  effects of Y.1711 on  
> stuff that does
> David> not exist  and has  not yet  been specified. This  is 
> in  addition to
> David> asking it's impact on proprietary implementations 
> where to date there
> David> has been under-specification 
> 
> It is perfectly reasonable to ask whether the ITU foresees 
> extending the OAM
> mechanisms in such a  way as to impact any of the  existing 
> or even foreseen
> label  distribution and/or  routing protocols  and 
> mechanisms.   It  is also
> perfectly reasonable to ask about the impact of those 
> mechanisms on existing
> deployments and implementations.  One can of course offer a 
> bunch of trumped
> up excuses  for not wanting to answer  the question, but 
> perhaps  that is an
> answer in itself.
> 
>

---

From: George Swallow <[email-masked]>
Date: Wed, 17 Apr 2002 10:58:41 -0400

David -

Since I was the one who put PIM on the list, let me explain.  I don't
consider it an unreasonable hurdle.  The question is simply this.

First an implementation of MPLS with PIM exists.  Since PIM itself is
not yet standard, there has been little pressure to push the former
along.  But it isn't completely a future consideration.

MPLS (unlike ATM) has a unified dataplane which can be directly
accessed by multiple control planes.  If an OAM scheme depends on
moving information through the control plane, and if OAM support is
presummed on every LSP as my reading of Y.1711 seems to imply then
presummably *every* MPLS control plane (current, in progress, or
future) needs some level of OAM awareness and interaction.  So I'd
like to understand where this is To: "David Allan" <[email-masked]>
cc: [email-masked]
Fcc: outbox
Subject: Re: response to ITU-T SG13 
In-reply-to: Your message of "Tue, 16 Apr 2002 10:30:32 EDT."
             <[email-masked]> 
--------
David -

Since I was the one who put PIM on the list, let me explain.  I don't
consider it an unreasonable hurdle.  

First an implementation of MPLS with PIM exists.  Since PIM itself is
not yet standard, there has been little pressure to push the former
along.  But it isn't completely a future consideration.

The question is simply this.

MPLS (unlike ATM) has a unified dataplane which can be directly
accessed by multiple control planes.  If an OAM scheme depends on
moving information through the control plane, and if OAM support is
presummed on every LSP as my reading of Y.1711 seems to imply, then
presummably *every* MPLS control plane (current, in progress, or
future) needs some level of OAM awareness and interaction.  So I'd
like to understand where this is headed.  If the ITU is envisioning
ubiquitous OAM support, it gets very onerous.  Not only do I have to
worry about supporting it in many protocols, but I also have to worry
about the interactions between protocols, like when I run LDP across
a tunnel created by RSVP.  

If on the other hand OAM can be deployed on a limited basis, then
things aren't as bad.  So the question is intended to get at the scope
of what the ITU is up to.

///George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824