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

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 12 Jan 2001 09:17:16 -0500

Eric,

Hate to drag this on But..

I am worried that making the LDP as a requirement and therefore
a +checkoff+ item for 2547 based VPN, may unnecessarily prohibit
some vendors to sell 2547 based VPN with RSVP (and minus LDP).

As per somebody's comment on nonog list about early MPLS deployments,
RSVP seems to be the "choice for MPLS Traffic Engineering and label switch 
path creation".

Do you think may be a text like following would then be more appropriate?

"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"

Himanshu
Tenor networks
Acton, MA

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 11:26 AM
To: Sasha Vainshtein
Cc: Alik; [email-masked]
Subject: Re: Requirement for LDP support in the RFC2547bis draft 

Sasha> I assume  that in both cases the  LSPs in question are  the paths for
Sasha> the outer (i.e., PE-to-PE)  level encapsulation, and that requirement
Sasha> for  LDP support  states  from the  fact  that such  a support  would
Sasha> gurantee ability to  create such an LSP, e.g.,  by requesting a label
Sasha> for the egress PE IP address (known to the ingress PE as the BGP next
Sasha> hop) in  a standard way. Is  this assumption correct? If  this is the
Sasha> case, do  the two quotations actually  refer to the  same problem and
Sasha> its solution?

Yes.  The requirement for LDP support  is there to ensure that two compliant
implementations can interoperate.  There is no requirement that LDP actually
be used, if some other method is available.

Sasha> I would  also like  to understand the  subtle difference  between the
Sasha> (lower case) "must" in the quoted sections of draft-rosen-rfc2547bis-
Sasha> 02.txt and the (capitalized keyword) MUST described in RFC2119.

I  don't think  there is  any difference  between "must"  and "MUST"  in the
section you quoted.

---

From: "Metz, E.T." <[email-masked]>
Date: Fri, 12 Jan 2001 15:43:23 +0100

on the other hand you are at the risk of making a "standard" that is
sufficiently open-ended that interoperability is no longer an option. i
think this is a big issue.

cheers,
	eduard

> ----------
> From: 	Shah, Himanshu[SMTP:[email-masked]]
> Sent: 	vrijdag 12 januari 2001 15:17
> To: 	[email-masked]'; Sasha Vainshtein
> Cc: 	Alik; [email-masked]
> Subject: 	RE: Requirement for LDP support in the RFC2547bis draft
> 
> Eric,
>

---

From: Barry Hass <[email-masked]>
Date: Fri, 12 Jan 2001 10:07:23 -0500

True. But my sense is that there are currently more vendors
delivering RSVP-TE than LDP. So what is the rationale for
choosing LDP as the standard for this application?

Barry

> From: Metz, E.T. [mailto:[email-masked]]
> Sent: Friday, January 12, 2001 9:43 AM
> To: [email-masked]'; Sasha Vainshtein; 'Shah, Himanshu'
> Cc: Alik; [email-masked]
> > Sasha> I assume  that in both cases the  LSPs in question 
> are  the paths
> > for
> > Sasha> for  LDP support  states  from the  fact  that such  
> a support
> > would
> > Sasha> gurantee ability to  create such an LSP, e.g.,  by 
> requesting a
> > label
> > Sasha> for the egress PE IP address (known to the ingress 
> PE as the BGP
> > next
> > Sasha> hop) in  a standard way. Is  this assumption 
> correct? If  this is
> > the
> > Sasha> case, do  the two quotations actually  refer to the  
> same problem
> > and
> > Sasha> its solution?
> > 
> > Sasha> I would  also like  to understand the  subtle 
> difference  between
> > the
> > I  don't think  there is  any difference  between "must"  
> and "MUST"  in
> > the
> > section you quoted. 
> > 
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 12 Jan 2001 10:01:53 -0500

I understand your point. But I am not sure if RSVP-TE draft
notes that it is only an alternative LSP setup method and
in order to be interoperable in MPLS deployments one must
support LDP. 

If that is true, then it would be unfair to
have service specifications on top of MPLS dictate one or
other LSP setup mechanism as the 'must' requirement, IMHO.

-----Original Message-----
From: Metz, E.T. [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:43 AM
To: [email-masked]'; Sasha Vainshtein; 'Shah, Himanshu'
Cc: Alik; [email-masked]
Subject: RE: Requirement for LDP support in the RFC2547bis draft

cheers,
	eduard

---

From: "Metz, E.T." <[email-masked]>
Date: Fri, 12 Jan 2001 17:24:30 +0100

I'm not exactly sure I understand what you mean with your remark on RSVP-TE.

What really is required for rfc2547bis VPN is that there is an LSP between a
PE and the BGP nexthop  (another PE) for the VPN traffic it needs to
forward. It is true that it does not really matter how this LSP gets there,
as long as it does. However, if you leave at this, there is no way to ensure
even minimal interoperability. Therefor, to ensure minimal interoperability
between multiple, different implementations one method of setting this LSP
has to be chosen. Since LDP is a basic label distribution protocol that does
the trick this seems to me a valid choice (out of static, RSVP -designed for
traffic engineering-, CR-LDP -designed for traffic engineering-, pigeons -to
pollute amsterdam-, etc ...)

In addition to minimal interoperability anyone is free to add more ways of
setting up the PE-to-PE LSPs.

I can understand your feeling of unfairness, in particular since base-MPLS
documents do not really lay down the law when it comes to label
distribution. However, these are the choices made (which have resulted in
the majority of vendors implementing RSVP-TE since traffic engineering was
the most interesting application ... ). But in general standards tend to
dictate, that is more or less what makes them standards.

cheers,
	Eduard

> Sent: 	vrijdag 12 januari 2001 16:01
> To: 	'Metz, E.T.'; [email-masked]'; Sasha Vainshtein; Shah, Himanshu
> Cc: 	Alik; [email-masked]

---

From: Jeff Parker <[email-masked]>
Date: Fri, 12 Jan 2001 11:35:55 -0500

> But in general standards tend to dictate, 
> that is more or less what makes them standards.

Agreed.  But it is a good dictator that manages to
stay out in front of where he people are going anyway.

- jeff parker

---

From: Barry Hass <[email-masked]>
Date: Fri, 12 Jan 2001 11:41:23 -0500

I think Himanshu's suggested wording, or something close
to it, is a reasonable compromise.

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: "Metz, E.T." <[email-masked]>
Date: Fri, 12 Jan 2001 19:44:10 +0100

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]