Subject: [PWE3] CR-LDP issue is a NONissue

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 22 Nov 2005 19:20:36 -0500

Yaakov,

It is curious that you emphatically deny that MS-LDP (i.e. LDP used for MS-PW setup) is CR-LDP and then conclude your email with a piece of history that suggests that you do see the current debate as a possible vindication of the protocol that lost the initial "contest" with RSVP-TE. 

You say that MS-LDP is not CR-LDP but a "different" augmentation of LDP. How different is it?

1) The argument made by Sasha in a recent email and by others before is that MS-LDP is UD whereas CR-LDP is DoD. However, that is a distortion of the PW setup procedure.  PW setup has nothing to do with unsolicited label distribution. A PW is only considered established if there has been a message exchange between the two T-PEs. It is more accurate to see MS-LDP as CR-LDP with support of bi-directional LSPs. This behavior is specified in RFC3472, with the difference that the RFC assumes that the initiating node sends Request message rather than a mapping message.

2) Draft-balus-bocci-martini-dyn-ms-pwe3 specifies a Bandwidth TLV that essentially performs the same role as CR-LDP's Traffic TLV.

3) Draft-balus-bocci-martini-dyn-ms-pwe3 specifies the optional use of an Explicit Route TLV

I continue to believe that there are no significant differences between MS-LDP and PW-LDP.

The question is: does it matter that MS-LDP is an extension of of CR-LDP and does it matter that we may be adding more and more features that do already exist in RSVP-TE? You don't seem to think so ("the decision to terminate work on CR-LDP ... has no impact on PWE"). Others seem to have the same view. E.g. Andy states his opposition to RSVP-TE as "No, unless there is a demonstrated requirement from the SPs that absolutely cannot be satisfied using MS-LDP". It is likely that by adding enough features, MS-LDP could meet all SP requirements. However, why waste resources (in standardization, implementation and deployment) by reinventing a mature protocol? How many RSVP-TE features do we have to identify before people agree that it might not be wise to go forward with MS-LDP? (This is not a rhetorical question.) 

Peter 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Yaakov Stein
> Sent: Monday, November 21, 2005 11:49 PM
> To: pwe3
> Subject: RE: [PWE3] Inter-op is not necessary
> 
> 
> Here is my (re)vote:
> 
> Q1. Are you in favor of moving MS-LDP forward as WG draft?
> A1. Yes. Please note that the CR-LDP issue is a NONissue.
>     First, the decision to terminate work on CR-LDP was
>     purely an MPLS WG decision, and has no impact on PWE.
>     Second, what is being proposed is NOT CR-LDP,
>     but rather a different augmentation of LDP.
> 
> Q2. Are you against moving MS-LDP forward?
> A2. No. (Isn't the answer to this question always strongly
> anticorrelated to A1?)
> 
> Q3. Are you in favor of moving MS-RSVP forward as WG draft?
> A3. No, as I do not see any advantage at this time.
>     although I understand its advantages.    
>     But I do not object to the authors continuing to work on this
>     and presenting their results to the WG.
> 
> Q4. Are you against moving MS-RSVP forward?
> A4. Not strongly, but once again I believe this answer MUST strongly
>     antocorrelate to A3.
> 
> Q5. Are you in favor of a single solution?
> A5. Absolutely. We do not want to have to build signaling interworking
> functions.
>     It is bad enough that for historical reasons we have so many
> protocols
>     so many interworking functions,
>     why would we want to knowingly recreate this situation for new
> protocols ?
>     
> 
> Aside: in another standardization in which I was involved,
> namely modem DSP design, we had a similar situation of two alternative
> approaches, each of which was stronger at one point in time
> and later weaker. The QAM approach won out in V.34 just as RSVP-TE
> one the first round here. Then in ADSL the DMT approach succeeded
> (think LDP).
> The final battle was for VDSL, and both sides dragged the discussion
> on for years (claiming that more data was needed in order to decide), 
> to the detriment of the community and end-users.
> The final result was DMT plus a weak allowance of QAM.
> 
> I would hope that we don't drag the discussions on here for years,
> and would strongly suggest not allowing a secondary approach,
> which merely confuses and segments the community. 
> 
> 
> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 23 Nov 2005 10:43:10 +0100

peter, all,

Busschbach, Peter B (Peter) wrote:

> Yaakov,
> 
> It is curious that you emphatically deny that MS-LDP (i.e. LDP used
> for MS-PW setup) is CR-LDP and then conclude your email with a piece
> of history that suggests that you do see the current debate as a
> possible vindication of the protocol that lost the initial "contest"
> with RSVP-TE.
> 
> 1) The argument made by Sasha in a recent email and by others before
> is that MS-LDP is UD whereas CR-LDP is DoD. However, that is a
> distortion of the PW setup procedure.  PW setup has nothing to do
> with unsolicited label distribution. A PW is only considered
> established if there has been a message exchange between the two
> T-PEs. It is more accurate to see MS-LDP as CR-LDP with support of
> bi-directional LSPs. This behavior is specified in RFC3472, with the
> difference that the RFC assumes that the initiating node sends
> Request message rather than a mapping message.

agreed

the reason why this happened is simply because the track followed by LDP 
PW sig. for was not kept in-line with the work done for CR-LDP (at that 
time no one probably did foresee the situation we are facing today) but 
this is indeed another method for achieving bi-directional mapping

in brief, maintaining this difference as PW-specific (for which i have 
heard some big theories) is not justified anymore

> 2) Draft-balus-bocci-martini-dyn-ms-pwe3 specifies a Bandwidth TLV
> that essentially performs the same role as CR-LDP's Traffic TLV.

agreed - i think this has been mentioned several times already - and i 
see this as a way know to further create additional differences

> 3) Draft-balus-bocci-martini-dyn-ms-pwe3 specifies the optional use

the ER-TLV is also optional in RFC3212

> The question is: does it matter that MS-LDP is an extension of of
> CR-LDP and does it matter that we may be adding more and more
> features that do already exist in RSVP-TE? You don't seem to think so
> ("the decision to terminate work on CR-LDP ... has no impact on
> PWE"). Others seem to have the same view. E.g. Andy states his
> opposition to RSVP-TE as "No, unless there is a demonstrated
> requirement from the SPs that absolutely cannot be satisfied using
> MS-LDP". It is likely that by adding enough features, MS-LDP could
> meet all SP requirements. However, why waste resources (in
> standardization, implementation and deployment) by reinventing a
> mature protocol? How many RSVP-TE features do we have to identify
> before people agree that it might not be wise to go forward with
> MS-LDP? (This is not a rhetorical question.)

the key question WG chairs should thus ask is whether this WG wants to 
work on a third application specific solution - call it X - and/or 
re-use one or both of the existing protocol solutions being CR-LDP/ RSVP-TE

now, technically speaking being an SPVC "pseudo-circuit" signaling why 
does make MS-PW soooooo... specific that their signaling can not be 
addressed by CR-LDP (being the IP flavour of ATM VC/VP signaling) and/or 
RSVP-TE ... the response is obvious

> Peter
> 
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Yaakov Stein Sent:
>> Monday, November 21, 2005 11:49 PM To: pwe3 Subject: RE: [PWE3]
>> Inter-op is not necessary
>> 
>> 
>> Here is my (re)vote:
>> 
>> Q1. Are you in favor of moving MS-LDP forward as WG draft? A1. Yes.
>> Please note that the CR-LDP issue is a NONissue. First, the
>> decision to terminate work on CR-LDP was purely an MPLS WG
>> decision, and has no impact on PWE. Second, what is being proposed
>> is NOT CR-LDP, but rather a different augmentation of LDP.
>> 
>> Q2. Are you against moving MS-LDP forward? A2. No. (Isn't the
>> answer to this question always strongly anticorrelated to A1?)
>> 
>> Q3. Are you in favor of moving MS-RSVP forward as WG draft? A3. No,
>> as I do not see any advantage at this time. although I understand
>> its advantages. But I do not object to the authors continuing to
>> work on this and presenting their results to the WG.
>> 
>> Q4. Are you against moving MS-RSVP forward? A4. Not strongly, but
>> once again I believe this answer MUST strongly antocorrelate to A3.
>> 
>> 
>> Q5. Are you in favor of a single solution? A5. Absolutely. We do
>> not want to have to build signaling interworking functions. It is
>> bad enough that for historical reasons we have so many protocols so
>> many interworking functions, why would we want to knowingly
>> recreate this situation for new protocols ?
>> 
>> 
>> Aside: in another standardization in which I was involved, namely
>> modem DSP design, we had a similar situation of two alternative 
>> approaches, each of which was stronger at one point in time and
>> later weaker. The QAM approach won out in V.34 just as RSVP-TE one
>> the first round here. Then in ADSL the DMT approach succeeded 
>> (think LDP). The final battle was for VDSL, and both sides dragged
>> the discussion on for years (claiming that more data was needed in
>> order to decide), to the detriment of the community and end-users. 
>> and would strongly suggest not allowing a secondary approach, which
>> merely confuses and segments the community.
>> 
>> 
>> Y(J)S
>> 
>> _______________________________________________ pwe3 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
>> 
> 
> 
> _______________________________________________ pwe3 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> 
> .
>

---

From: [email-masked]
Date: Wed, 23 Nov 2005 13:50:21 +0100

> re-use one or both of the existing protocol solutions being CR-LDP/ RSVP-TE

Dimitri,

I think you have raised a very interesting question.

My understanding is that LDP was designed for label distribution purposes
without TE requirements. For any other applications where TE is required,
RSVP-TE and CR-LDP were designed and later on CR-LDP was deprecated (so RSVP-TE
is the only standard solution).

If we look at the SS-PW application, the requirement is to have a label
distribution mechanism of the PW label between the PEs and therefore using LDP
is a "good enough" solution.
Nobody has objected to this idea because there were no arguments in favour of
RSVP-TE with such an application scope.

Now we are looking at the MS-PW application.

If there are no TE requirements therefore LDP is still a "good enough" solution.

However there are MS-PW applications where TE is required. For these
applications I think that it is wiser, from a standardization as well as an
implementation point of view, to reuse all the work done and still on-going in
MPLS and CCAMP WG on RSVP-TE.

I do not think it is good that PWE3 starts working on a "new flavour" of CR-LDP
in a full overlapping with MPLS and CCAMP WGs.

Italo