Subject: RE: Requirement for LDP support in the RFC2547bis draft

From: Barry Hass <[email-masked]>
Date: Fri, 12 Jan 2001 16:31:37 -0500

Eduard,

In theory, I agree with you. But in this particular case, specifying
a requirement for one signalling protocol is liable to lead to a
discussion of which one it should be. And I REALLY don't want to go
there.

I think your suggested wording is fine. Thank you for translating
the original suggestion into standard draft-speak.

As an aside, and keeping in mind that I don't want to start a discussion
of the merits of the choice, I would be curious to know why the authors
of 2547 chose LDP, rather than RSVP-TE as a standard for interoperability.

Barry

> -----Original Message-----
> From: Metz, E.T. [mailto:[email-masked]]
> Sent: Friday, January 12, 2001 1:44 PM
> To: Metz, E.T.; [email-masked]'; Sasha Vainshtein; 'Shah, 
> Himanshu';
> 'Barry Hass'
> Cc: Alik; [email-masked]
> Subject: RE: Requirement for LDP support in the RFC2547bis draft
> 
> 
> I do not really like trading required (always interoperable), 
> for something
> less (if you're lucky)
> 
> If the requirement is to be removed anyway, then I'd suggest to make:
> - LDP RECOMMENDED / SHOULD be supported, 
> - any other method OPTIONAL / MAY be supported, 
> - and the presence of the PE-to-PE LSPs REQUIRED / MUST be there. 
> ("desirable" has no real meaning to it, "should" more or less 
> represents
> what Barry describes below as "encouraging LDP support")
> 
> cheers,
> 	Eduard
> 
> ps may "any other method" should be somewhat limited to a 
> smaller, more
> standard set of methods.
> 
> > ----------
> > From: 	Barry Hass[SMTP:[email-masked]]
> > Sent: 	vrijdag 12 januari 2001 17:41
> > To: 	Metz, E.T.; [email-masked]'; Sasha 
> Vainshtein; 'Shah, Himanshu'
> > Cc: 	Alik; [email-masked]
> > Subject: 	RE: Requirement for LDP support in the RFC2547bis draft
> > 
> > I think Himanshu's suggested wording, or something close
> > to it, is a reasonable compromise.
> > 
> > "support for LDP as a mean for LSP setup is desirable for 
> the guarenteed
> > interoperability purposes. However, there is no requirement 
> that LDP 
> > actually be used, if some other method is available"
> > 
> > I read this as encouraging LDP support for interoperability
> > purposes, but allowing vendors who don't have it to still claim
> > compliance with the spec, albeit under a limited set of conditions.
> > 
> > Can people live with that?
> > 
>

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 12 Jan 2001 15:07:00 -0800 (PST)

>>>>> "Barry" == Barry Hass <[email-masked]> writes:

    Barry> As an aside, and keeping in mind that I don't want to start
    Barry> a discussion of the merits of the choice, I would be
    Barry> curious to know why the authors of 2547 chose LDP, rather
    Barry> than RSVP-TE as a standard for interoperability.

With LDP you have much less signaling to do... you have it assign
labels for your possible paths and you are just using your IGP to pick
the shortest-path. RSVP + a path computation tool requires
significantly more signaling in the network and it is an overkill on
the simplest case since typically an explicit path is not needed.

LDP + IGP will also converge faster than IGP + path computation tool +
RSVP, unless you calculate an very substantial number of backup paths.

These are different tools for different problem sets...  LDP maps well
to the problem of providing full-mesh LSP connectivity to all edges of
your network following IGP shortest path. Computing explicit paths
maps well to divert parts of your traffic from shortest path.

You can* use explicit paths (+ whatever signaling protocol your fancy)
to run a tag vpn network on top. But that is not the simplest solution
to the problem and it will (most likely) require engineering the
network apropriatly.

  Pedro.

*It would be actually interesting to know how far a full mesh
edge-to-edge of explicit paths would scale.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 12 Jan 2001 15:32:49 -0800

In addition to what Pedro already said let me add a comment that running
a mpls-vpns on mpls-te only without LDP is a quite challanging task. TE
in genral was build to optimize the routing paths. When it fails for
whatever reason you fall back to pure IP and IP reachability is fine. 

When TE fails for whatever reason while you are using it for mpls-vpns
your 10s or 100s of customers connected to given PEs are simply
unreachable with the peers to which PE's broken TE tunnel was going to.
P routers do not maintain any of the VPN information.

I am not going to bring here all protection you can use for TE just
wanted to bring up this point. LDP by it's nature has much more less
constrains which could cause it to fail and in most of today's
implementations I have seen can be as robust as the IGP you are running.

R.

> Pedro Roque Marques wrote:
>