Subject: RE: RSVP Hello

From: [email-masked]
Date: Fri, 24 Aug 2001 17:57:41 +0100

Bill/Martin,

Noting your comment (Bill) on cringing when you hear "It will be easy to add
this fuctionality" or "how hard can this be?", I cringe myself when I see
architectural kludges, and this thread has more than a whiff of these.....so
let me add my 2 cents (with a slightly different slant...so please bear with
me):

Each protocol provides specific functionality (otherwise why have it?).
Hence, by inference, each protocol will have it own specific failure modes,
and thus require its own specific OAM mechanism.  So whether we are talking
about RSVP, LDP, OSPF, BGP4, etc this applies, and the RFCs that specify
these protocols do indeed have such OAM functionality defined in them.

Now each of these protocols gets transported between the nodes (and their
respective functional processes therein) via data-plane trails of some
description, eg SDH VC-4s, ATM VPs/VCs, MPLS LSPs, etc as appropriate for
the network situation considered.

In the case of a true cnls-only layer network then all the above protocols
go hop-by-hop via IP.  So, since one can say there is always topological
congruence between the data-plane and the control-plane protocols in this
case, then one could allow control-plane protocols to proxy for detecting
data-plane failures.......but there will still be (more general) nodal or
specific protocol failure modes where the specific control-protocol OAM is
needed anyway.

When we consider co fabrics one cannot always guarantee there will be
data-plane and control-plane protocol topological congruence.  Indeed, it is
usually far more efficient if they are not topologically congruent.  This
should be obvious to those working on GMPLS, as indeed it has been obvious
to those in the Telecoms industry for a long time.  Hence, the data-plane
that carries the customer traffic is likely to be different topologically
(and maybe even technologically) to the data-plane that carries the
control-plane protocols (or indeed the management-plane protocols...and
there is actually no need for these to use the same data-plane as the
control-plane protocols;  especially if one wants a very robust network
architecture such that the management-plane is completely isolated from the
control-plane protocols, eg to protect against some pathological failure
mode of a control-plane protocol).  A further point here is that the
data-plane OAM is relevant only to the layer network considered (ie SDH/VC4
OAM functionality is different to ATM/VP OAM functionality is different to
MPLS/LSP OAM functionality, is different to IP/ICMP OAM functionality,
etc.), and it must never be dependent of some other specific client or
server layer network OAM. 

The above is really common sense, but we need this architectural discipline
in order to allow:
(i) configuration flexibility (eg data/control/management plane config or
the protocol choices therein);
(ii) consistent data-plane interworking with operational support systems
irrespective of control-plane protocols used (eg consistent fault
management, SLA verification, billing);
(iii) future development independence of data/control/management-plane
protocols (ie add/change/remove).

So, for example, whether I run layer network technology 'X' using RSVP-TE,
CR-LDP, PNNI, sig_prot_Y or indeed *no* signalling protocols I want the OAM
for the data-plane trails that carry the customer traffic to be independent
of the signalling protocol choice. This will be true in the case of SDH VC-4
trails say, but it is unfortunately not true for MPLS LSPs since we don't
have any decent MPLS data-plane OAM agreed yet.

This mail thread is mixing different signalling protocol functionality as
proxies for data-plane failures, and a previous discussion on the
draft-pan-lsp-ping-01.txt broke the layer/plane protocol independence
principle by binding specific client/server layer OAM functionality to a
specific control-plane signalling protocol.

During the discussion of the Ping draft, I know Yakov described what I have
discussed above as 'working on LTSFGTC' (long-term solutions for generations
to come)...or something like that......but if we want MPLS itself to be a
LTSFGTC (and hopefully also give some solid foundation for those working in
the PWE3 and PPVPNs WGs) then we really have to get some of the basic OAM
architectural tenets right at the outset.  Proper data-plane OAM, and its
decoupling from other client/server layer data-planes and/or specific
control (or management) plane protocols is not a 'luxury item', its just
plain common sense to avoid problems down the road.

regards, Neil
> -----Original Message-----
> From: Sanford, Bill [mailto:[email-masked]]
> Sent: 24 August 2001 14:27
> To: 'Martin, Christian'; Sanford, Bill; [email-masked]'
> Subject: RE: RSVP Hello
> 
> 
> > -----Original Message-----
> > From: Martin, Christian [mailto:[email-masked]]
> > Sent: Thursday, August 23, 2001 6:42 PM
> > To: 'Sanford, Bill'; [email-masked]'
> > Subject: RE: RSVP Hello
> > 
> > 
> > If I may comment here from an operational perspective...
> > 
> > I think the Hello mechanism, as specified, could be extended 
> > to occur upon
> > link initialization.  One of my most frustrating experiences 
> > with RSVP state
> > was when a new link was turned up with a fat-fingered 
> > authentication key.
> > Since there is no initial RSVP state acorss the link until a 
> > PATH message
> > needs to be sent, I was unaware of it until I had to 
> > troubleshoot a label
> > request across 13 routers.  Were it part of the 
> specification to send
> > Hello's and build an adjaceny during link intialization, it 
> > would have been
> > something detectable during configuration.
> 
> That sounds like a RSVP-TE that wants to be LDP. RSVP doesn't 
> do this. Why
> have LDP if RSVP is going to behave like it.
> 
> > Perhaps the draft can be extended to address this operational 
> > need?  How
> > difficult would it be to add:
> > 
> > "Upon link initialization, an interface MAY/SHOULD 
> > immediately send an RSVP
> > hello to the all routers multicast address on broadcast 
> > media, or to its
> > direct neighbor on ptp media.  For each RSVP hello received, 
> > record the
> > source IP address in the RSVP adjacency table.  Transmit 
> hello's every
> > configurable interval."
> 
> Adding more confusion to who is going to do what, when, and 
> how it will
> interoperate with RSVP (not-TE) and the omnipotent "cloud" 
> brings another
> level of frustration to the already miniscule timelines of project
> completion. But, maybe it's just me. I cringe every time I 
> hear "It will be
> easy to add this fuctionality" or "how hard can this be?" 
> 
> > Of course, this example discusses authenticated RSVP 
> > messages, but other
> > types of issues can impair RSVP without easy detection.  As 
> > it is today, you
> > can either send a test PATH message across the network to 
> > build state, or
> > you can hope it works when you need it.  Neither is operationally
> > acceptable, IMHO.
> 
> You can always submit a draft. ;-)
> 
> Regards,
> Bill
>

---

From: Ping Pan <[email-masked]>
Date: Sat, 25 Aug 2001 23:01:18 -0700

> specific control-plane signalling protocol.

Sigh,,, after reading through this mail, I can relate to the feeling 
some people have on MPLS, that is, it's an ATM replacement. :-( I really 
hope not.

Normally, the buzzwords such as "layers", "principles" and 
"architectures" are defined to make it easier to describe things. They 
are not defined to create new religions. Sometimes, they are more useful 
to marketing than to engineering. So if something is useful to the 
Internet, we try to come up with a simple solution and just build it. 
There is no magic to this process. So instead of talking about how I 
have broken the layers, principles, architectures and religious rules in 
LSP-ping, tell me why it does not work for the purpose it was designed for.

> architectural tenets right at the outset. 

If OAM is a great LTSFGTC, then there is nothing to be worried about on 
this "narrow-focused" LSP-ping. We do our work, and you do yours. What a 
beautiful thing!

> Proper data-plane OAM, and its

It's also a common sense that in order to make MPLS working in the 
Internet, we need to keep it simple.

Regards,

- Ping

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Aug 2001 14:07:26 +0200

All,

would very much like to echo Pings sentiment in this, and also go
so far as to suggest (I know I'm at risk of being accused of bringing
the chinese Red Guards back to life) a correction movement within the 
WG, aiming at taking out everything that is not needed/useful.

/Loa

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se