Subject: RE: [PWE3] Inter-op is not necessary

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Nov 2005 22:14:11 +0200

> To be clear, I said that "coexistance" was a necessity to be
documented by the WG. 
> Whether coexistance equates to interworking depends on the MS
requirements.

Since the whole idea of MPLS MS-PWs is to facilitate the interworking of
different
operators, as far as I see coexistence must mean either

1) fully interwork
2) mandate that they never have to cooperate.

The latter would probably end up with everyone
having to support both signaling protocols, 
and often setting up additional PWs just to circumvent
the limitation.

Y(J)S

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

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 14 Nov 2005 16:36:25 -0500

Hi Eric,

I disagree with your assertion on narrow view. 
MS-PW would very well be used across multiple admin domains.
We certainly do not want two solutions of MS-PW; one for single
and other for multiple admin domain.

If two solutions are allowed to progress, all S-PEs will have
to support both solutions.

I support selecting one (whatever that may be) solution only.
The co-existence argument is rather weak.

/himanshu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Gray, Eric
> Sent: Monday, November 14, 2005 3:39 PM
> To: 'Yaakov Stein'; Mark Townsley; [email-masked]
> Subject: RE: [PWE3] Inter-op is not necessary
> 
> 
> Yaakov,
> 
> 	This is a very narrow view of the purpose for multi-segment
> pseudo-wires.  There are applications for pseudo-wire stitching 
> within a single administrative domain.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked] [mailto:[email-masked]] 
> --> On Behalf Of Yaakov Stein
> --> Sent: Monday, November 14, 2005 3:14 PM
> --> To: Mark Townsley; [email-masked]
> --> Subject: RE: [PWE3] Inter-op is not necessary
> --> 
> -->  
> --> > To be clear, I said that "coexistance" was a necessity to be
> --> documented by the WG. 
> --> > Whether coexistance equates to interworking depends on the MS
> --> requirements.
> --> 
> --> Since the whole idea of MPLS MS-PWs is to facilitate the 
> --> interworking of different operators, as far as I see 
> --> coexistence must mean either
> --> 
> --> 1) fully interwork
> --> 2) mandate that they never have to cooperate.
> --> 
> --> The latter would probably end up with everyone having to 
> --> support both signaling protocols, and often setting up 
> --> additional PWs just to circumvent the limitation.
> --> 
> --> Y(J)S
> --> 
> --> _______________________________________________
> --> pwe3 mailing list
> --> [email-masked]
> --> https://www1.ietf.org/mailman/listinfo/pwe3
> --> 
>

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 14 Nov 2005 20:17:20 -0200

Himanshu,

	You and Andy would apparently like to have people believe that
I suggested an even narrower view than Yaakov did.  Of course we want
any solution we come up with to be useful in a multiple administrative
domain application.  And certainly this must be the case by the time
such applications are in use.

	I objected to Yaakov's statement that the "whole idea" is to 
support multiple domains and the continuation of that idea to infer 
that solutions must either interoperate or "never" cooperate.  In the
first place, it is not too difficult to determine that it is possible
to make the proposed solutions interoperate.  That was demonstrated
some time ago and interoperability can be shown to be largely - if not
entirely - a local matter.  And, in the second place, never is a big
word when applied to a subset of the possible applications.

	That does not mean I disagree with Yaakov's (or your) assertions
about protocol complexity, etc.

	There are other issues that I am trying to get my head around,
however, and - until I do - I am not yet ready to agree with you and
Andy...

--
Eric

--> -----Original Message-----
--> From: Shah, Himanshu [mailto:[email-masked]] 
--> Sent: Monday, November 14, 2005 4:36 PM
--> To: Gray, Eric; Yaakov Stein; Mark Townsley; [email-masked]
--> Subject: RE: [PWE3] Inter-op is not necessary
--> 
--> Hi Eric,
--> 
--> I disagree with your assertion on narrow view. 
--> MS-PW would very well be used across multiple admin domains.
--> We certainly do not want two solutions of MS-PW; one for 
--> single and other for multiple admin domain.
--> 
--> If two solutions are allowed to progress, all S-PEs will 
--> have to support both solutions.
--> 
--> I support selecting one (whatever that may be) solution only.
--> The co-existence argument is rather weak.
--> 
--> /himanshu
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of 
--> > Gray, Eric
--> > Sent: Monday, November 14, 2005 3:39 PM
--> > To: 'Yaakov Stein'; Mark Townsley; [email-masked]
--> > Subject: RE: [PWE3] Inter-op is not necessary
--> > 
--> > 
--> > Yaakov,
--> > 
--> > 	This is a very narrow view of the purpose for multi-segment 
--> > pseudo-wires.  There are applications for pseudo-wire 
--> stitching within 
--> > a single administrative domain.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [email-masked] [mailto:[email-masked]] On 
--> > --> Behalf Of Yaakov Stein
--> > --> Sent: Monday, November 14, 2005 3:14 PM
--> > --> To: Mark Townsley; [email-masked]
--> > --> Subject: RE: [PWE3] Inter-op is not necessary
--> > --> 
--> > -->  
--> > --> > To be clear, I said that "coexistance" was a necessity to be
--> > --> documented by the WG. 
--> > --> > Whether coexistance equates to interworking depends 
--> on the MS
--> > --> requirements.
--> > --> 
--> > --> Since the whole idea of MPLS MS-PWs is to facilitate the 
--> > --> interworking of different operators, as far as I see 
--> coexistence 
--> > --> must mean either
--> > --> 
--> > --> 1) fully interwork
--> > --> 2) mandate that they never have to cooperate.
--> > --> 
--> > --> The latter would probably end up with everyone having 
--> to support 
--> > --> both signaling protocols, and often setting up 
--> additional PWs just 
--> > --> to circumvent the limitation.
--> > --> 
--> > --> 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: "Gray, Eric" <[email-masked]>
Date: Tue, 15 Nov 2005 21:35:19 -0200

Andy,

	There is a bit of anachronism in this interpretation.  As
I recall from the time, it might be slighly more accurate to say
the most credible router vendors went the same way - but that may
seem to cast aspersions against other router vendors in the arena
at the time - which would be at least unfair. It might also seem
to imply that credibility was derived from technical correctness
and that would be a bit of a stretch.

	When the majority of wrangling over protocol choices for 
traffic engineering was taking place, one of the two router 
vendors that chose to go the "same way" was a start-up company
just having obtained their second round of funding for - I seem
to recall a total investment of about 51 million dollars (hardly
enough to establish them as a dominant router vendor - no matter
what occurred later).

	What made that vendor as credible as any other was the clear
alignment they had with one of the more credible service providers
(which also happened to be the one fostering the idea of traffic
engineering in the first place).  Other router vendors were less 
"credible" because they were not getting traction with service 
providers (especially the one that was the largest customer that 
had already indicated an intent to pay real money for TE-capable 
routing equipment).

	In retrospect, the router vendors that chose to go with the
RSVP-TE signaling choice ended up as the dominant router vendors
- and that (I believe) is the result of having the market make the
choice.

	I think we all know that the IETF leadership is under some 
pressure to "make a choice".  However, unless it is really clear
that a choice can be made at this time, the IETF may not be the
right place to make that choice.  As much as people like to make
the "two protocols is worse than none" argument and use CR-LDP
and RSVP-TE as an example, any number of things could have made
things come out differently in that case.  

--
Eric

--> -----Original Message-----
--> From: Andrew G. Malis [mailto:[email-masked]] 
--> Sent: Tuesday, November 15, 2005 5:50 PM
--> To: LE ROUX Jean-Louis RD-CORE-LAN
--> Cc: Andrew G. Malis; Gray, Eric; Mark Townsley; Yaakov 
--> Stein; [email-masked]
--> Subject: RE: [PWE3] Inter-op is not necessary
--> 
--> JL,
--> 
--> Actually, some vendors did do both before it was clear 
--> where the market was going - and in this case, we had the 
--> advantage that both of the dominant router vendors went the 
--> same way, as did their customers.  But that was really the 
--> exception rather than the rule.
--> 
--> Cheers,
--> Andy
--> 
--> --------
--> 
--> At 11/15/2005 22:32 +0100, LE ROUX Jean-Louis RD-CORE-LAN wrote:
--> >Hi Andrew,
--> >
--> > >I'm not a fan
--> > > of "let the market decide"
--> > > because in the end, as a vendor you have to do both -
--> >
--> >Look at the RSVP-TE vs CR-LDP case, this is a good example, a bit 
--> >related to our case here by the way:-), were the market 
--> decided, and it 
--> >seems to me that not many vendors implemented both...
--> >
--> >Regards,
--> >
--> >JL
--> >
--> >
--> > > -----Message d'origine-----
--> > > De : [email-masked] 
--> [mailto:[email-masked]] De la part 
--> > > de Andrew G. Malis Envoyé : lundi 14 novembre 2005 
--> 21:59 À : Gray, 
--> > > Eric Cc : Mark Townsley; 'Yaakov Stein'; [email-masked] 
--> Objet : RE: 
--> > > [PWE3] Inter-op is not necessary
--> > >
--> > > Eric,
--> > >
--> > > Yeah, but we don't want to restrict it to a single 
--> administrative 
--> > > domain.  I also agree with many of the others in the 
--> meeting - let's 
--> > > choose one and move on.  I'm not a fan of "let the 
--> market decide"
--> > > because in the end, as a vendor you have to do both - 
--> especially if 
--> > > big vendor a goes one way, big vendor b goes the other, 
--> and everyone 
--> > > else needs to interoperate with both a and b.  And most 
--> times, even 
--> > > the big vendors find that their customers want them to 
--> interoperate 
--> > > with their competition, so they end up doing it both 
--> ways as well.
--> > >
--> > > The only way we should approve both is if we can define 
--> a completely 
--> > > dynamic interface between the two that requires no more 
--> provisioning 
--> > > by the service providers than if we had only chosen 
--> one.  Otherwise, 
--> > > we're shortchanging the operators and the rest of the community.
--> > >
--> > > Cheers,
--> > > Andy
--> > >
--> > > -------
--> > >
--> > > At 11/14/2005 18:39 -0200, Gray, Eric wrote:
--> > > >Yaakov,
--> > > >
--> > > >         This is a very narrow view of the purpose for 
--> > > >multi-segment pseudo-wires.  There are applications 
--> for pseudo-wire
--> > > stitching within
--> > > >a single administrative domain.
--> > > >
--> > > >--
--> > > >Eric
--> > > >
--> > > >--> -----Original Message-----
--> > > >--> From: [email-masked] 
--> [mailto:[email-masked]] On 
--> > > >--> Behalf Of Yaakov Stein
--> > > >--> Sent: Monday, November 14, 2005 3:14 PM
--> > > >--> To: Mark Townsley; [email-masked]
--> > > >--> Subject: RE: [PWE3] Inter-op is not necessary
--> > > >-->
--> > > >-->
--> > > >--> > To be clear, I said that "coexistance" was a 
--> necessity to be
--> > > >--> documented by the WG.
--> > > >--> > Whether coexistance equates to interworking 
--> depends on the MS
--> > > >--> requirements.
--> > > >-->
--> > > >--> Since the whole idea of MPLS MS-PWs is to facilitate the 
--> > > >--> interworking of different operators, as far as I see 
--> > > >--> coexistence must mean either
--> > > >-->
--> > > >--> 1) fully interwork
--> > > >--> 2) mandate that they never have to cooperate.
--> > > >-->
--> > > >--> The latter would probably end up with everyone having to 
--> > > >--> support both signaling protocols, and often setting up
--> > > additional PWs just
--> > > >--> to circumvent the limitation.
--> > > >-->
--> > > >--> Y(J)S
--> > >
--> > >
--> > > _______________________________________________
--> > > pwe3 mailing list
--> > > [email-masked]
--> > > https://www1.ietf.org/mailman/listinfo/pwe3
--> > >
-->

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 15 Nov 2005 21:23:34 -0500

Folks,

It looks to me we went through this type of situation
in the past in more than one instance and I believe that
without a clear analysis, guidelines/process and decision 
at whole ietf level (not each time leaving *just* the wg to 
make the choice -though nothing wrong with that if it succeeds 
in making such choice in a timely manner!) I am afraid we will again 
encounter such situations and the same arguments will be 
played again and again.

>From past experience, at certain point it is not really the 
technical arguments that count in this debate but really which 
factors are deemed important for which group supporting a
given proposal (including the group that looks at just
complexity of standardization efforts). 

For example these factors can be:

- let the market decides (though "market decides" needs
  some form of definition).
- avoid wg extra efforts (like define interoperability
  mechanism, avoid duplicate efforts, etc.
- try to always build on existing close standards in incremental way
 (note that if this argument was really strong CR-LDP will have 
  made it ;-)).
- adopt solutions that have significant market preference 
  (again market may prefer several ones) and market
  preference can shift with time.
- etc...

It is really which factors we (ietf in general and pwe3 in
particular) think is *important* that will guide the final choice.

My suggestion is instead of rehashing the same previous debates, 
why not have ietf/iesg, both? look at this problem
and provide some clear guidelines/process (or decisions)  
and let pwe3 members work on what they believe are interested in 
(one or two proposal, etc) in early stages. 

Maybe one completely different outcome of such analysis 
is to acknowledge that these situations will happen in certain 
situations at early stages of standard efforts and it maybe 
difficult to make clear cut choice, then document 
the factors that wg used to adopt 
which proposal and revisit such decision within a time
period, or any other proposal...

Hamid.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gray, Eric
> Sent: Tuesday, November 15, 2005 6:35 PM
> To: 'Andrew G. Malis'; LE ROUX Jean-Louis RD-CORE-LAN
> Cc: Yaakov Stein; [email-masked]; Mark Townsley
> I recall from the time, it might be slighly more accurate to 
> say the most credible router vendors went the same way - but 
> that may seem to cast aspersions against other router vendors 
> in the arena at the time - which would be at least unfair. It 
> might also seem to imply that credibility was derived from 
> technical correctness and that would be a bit of a stretch.
> 
> vendors that chose to go the "same way" was a start-up 
> company just having obtained their second round of funding 
> for - I seem to recall a total investment of about 51 million 
> dollars (hardly enough to establish them as a dominant router 
> vendor - no matter what occurred later).
> 
> 	What made that vendor as credible as any other was the 
> clear alignment they had with one of the more credible 
> service providers (which also happened to be the one 
> fostering the idea of traffic engineering in the first 
> place).  Other router vendors were less 
> 	In retrospect, the router vendors that chose to go with 
> the RSVP-TE signaling choice ended up as the dominant router vendors
> - and that (I believe) is the result of having the market 
> make the choice.
> 
> pressure to "make a choice".  However, unless it is really 
> clear that a choice can be made at this time, the IETF may 
> not be the right place to make that choice.  As much as 
> people like to make the "two protocols is worse than none" 
> argument and use CR-LDP and RSVP-TE as an example, any number 
> of things could have made things come out differently in that case.  
> 
> --
> Eric
> 
> 
> --> > > [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> --> > >
> --> 
>

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 17 Nov 2005 18:00:49 -0200

Andy,

	That's not how I recall the discussion at all, and that
is because the minutes fail to capture the actual results.

	As I recall, there was a lot of hands to accept each
draft as a working group document.  What was different was 
that for the LDP version there were no objections while for
the RSVP-TE version there were a few.

	This is one of the failings of our present basis for
"consensus shaving" in the IETF.  Whether or a minority is
in the way of a "rough consensus" depends a lot on who is
playing the part of "barber".

	Where the issue may have become confusing was when it
was pointed out (by several people) that this was equivalent
to indicating that both proposals should become WG drafts
and that would mean extra work to advance both through the
IETF, most people were - stated mildly - not in favor of 
that.

	Subsequent efforts to determine what that "state of
confusion" boiled down to were inconclusive.  That does not
mean that anyone is free to provide their personal spin as
to what we concluded at that meeting. The only determination
That is legitimate is that we determined nothing.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Andrew G. Malis
--> Sent: Thursday, November 17, 2005 2:28 PM
--> To: Drake, John E
--> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
--> Subject: RE: [PWE3] Inter-op is not necessary
--> 
--> John,
--> 
--> This is quoting from the minutes:
--> 
--> Dynamic Multi-Segment Pseudo Wire Signaling Procedures 
--> Using LDP Florin Balus ([email-masked]) 
--> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt
--> ....
--> Stewart Bryant: Who thinks this should be a WG draft: Large 
--> number in favour
--> 
--> Setup and Maintenance of Pseudowires using RSVP-TE Dimitri 
--> Papadimitriou draft-raggarwa-rsvpte-pw-02.txt .....
--> Stewart Bryant: Is there consensus to make this a WG draft?: a few. 
--> Will ask the question to the list.
--> 
--> 
--> The minutes also reflect what I saw at the meeting.
--> 
--> Cheers,
--> Andy
--> 
--> ---------
--> 
--> At 11/17/2005 10:55 -0800, Drake, John E wrote:
--> >Tom,
--> >
--> >I don't think you and Luca should be judging consensus, 
--> but since you 
--> >are, I would say that the consensus in the Vancouver 
--> meeting seemed to 
--> >be overwhelmingly in favor of advancing both.
--> >
--> >Thanks,
--> >
--> >John
--> >
--> > > -----Original Message-----
--> > > From: Thomas D. Nadeau [mailto:[email-masked]]
--> > > Sent: Thursday, November 17, 2005 7:36 AM
--> > > To: Mark Townsley
--> > > Cc: Yaakov Stein; [email-masked]
--> > > Subject: Re: [PWE3] Inter-op is not necessary
--> > >
--> > >
--> > > > LE ROUX Jean-Louis RD-CORE-LAN wrote:
--> > > >
--> > > >> Hi Andrew,
--> > > >>
--> > > >>
--> > > >>> I'm not a fan of "let the market decide" because in 
--> the end, as 
--> > > >>> a vendor you have to do both -
--> > > >>
--> > > >> Look at the RSVP-TE vs CR-LDP case, this is a good 
--> example, a bit 
--> > > >> related to our case here by the way:-), were the 
--> market decided, 
--> > > >> and it seems to me that not many vendors implemented both...
--> > > >>
--> > > > Ironically, the more split the WG is, the more 
--> important it is to 
--> > > > pick one path forward now. The closer we are to a 
--> 50/50 split, the 
--> > > > more likely everyone will end up implementing both, 
--> as well as the 
--> > > > interop between each given the interprovider 
--> requirements. This 
--> > > > additional overhead to interoperability only serves 
--> to inhibit 
--> > > > market forces.
--> > >
--> > >       I think its clear from the 2 or 3 times we have 
--> taken a poll 
--> > > on this that its not even close to 50-50; its more like 
--> 85-15. Luca 
--> > > raised this point during the last meeting, and it was 
--> evident from 
--> > > those in the room in Paris that there was a clear 
--> majority for the 
--> > > LDP-based solution. It might be true that the 
--> RSVP-TE-based solution 
--> > > gets implemented, but the question in my mind is who is 
--> actually 
--> > > going to *deploy and use* it? Following this argument, 
--> given its 
--> > > small potential for being deployed, would you ever need 
--> multiple 
--> > > vendors to interoperate on that solution based on an 
--> IETF standard? 
--> > > And should the IETF spend essentially equal WG 
--> resources developing 
--> > > such a solution?
--> > >
--> > >       I say we stop wasting the WG's resources and move 
--> forward on 
--> > > making the solution supported by the clear majority as 
--> solid and 
--> > > complete as possible.
--> > >
--> > >       --Tom
--> > >
--> 
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 17 Nov 2005 12:26:53 -0800

Andy,

I'm sorry, but I was not referring to the individual polls for making
each of the I-Ds a working group draft.  I was referring to an earlier
poll:

"Stewart Bryant: How many want one solution before progressing?: Quite a
few

Stewart Bryant: How many want to take them both progressed and make a
decision later?: substantially more."

Thanks,

John 

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Thursday, November 17, 2005 11:28 AM
> To: Drake, John E
> Cc: Thomas D. Nadeau; Mark Townsley; Yaakov Stein; [email-masked]
> John,
> This is quoting from the minutes:
> 
> Dynamic Multi-Segment Pseudo Wire Signaling Procedures Using LDP
> Florin Balus ([email-masked])
> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt
> ....
> Stewart Bryant: Who thinks this should be a WG draft: Large number in
> favour
> 
> Setup and Maintenance of Pseudowires using RSVP-TE
> Dimitri Papadimitriou
> draft-raggarwa-rsvpte-pw-02.txt
> .....
> Stewart Bryant: Is there consensus to make this a WG draft?: a few.
> Will ask the question to the list.
> 
> 
> The minutes also reflect what I saw at the meeting.
> 
> Cheers,
> Andy
> 
> ---------
> 
> At 11/17/2005 10:55 -0800, Drake, John E wrote:
> >Tom,
> >
> >I don't think you and Luca should be judging consensus, but since
> >you are, I would say that the consensus in the Vancouver meeting
> >seemed to be overwhelmingly in favor of advancing both.
> >
> >Thanks,
> >
> >John
> >
> > > From: Thomas D. Nadeau [mailto:[email-masked]]
> > > Sent: Thursday, November 17, 2005 7:36 AM
> > > To: Mark Townsley
> > > Cc: Yaakov Stein; [email-masked]
> > > Subject: Re: [PWE3] Inter-op is not necessary
> > >
> > >
> > > > LE ROUX Jean-Louis RD-CORE-LAN wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >>
> > > >>> I'm not a fan of "let the market decide" because in the end,
as a
> > > >>> vendor you have to do both -
> > > >>
> > > >> Look at the RSVP-TE vs CR-LDP case, this is a good example, a
bit
> > > >> related to our case here by the way:-), were the market
decided,
> > > >> and it seems to me that not many vendors implemented both...
> > > >>
> > > > Ironically, the more split the WG is, the more important it is
to
> > > > pick one path forward now. The closer we are to a 50/50 split,
the
> > > > more likely everyone will end up implementing both, as well as
the
> > > > interop between each given the interprovider requirements. This
> > > > additional overhead to interoperability only serves to inhibit
> > > > market forces.
> > >
> > >       I think its clear from the 2 or 3 times we have taken
> > > a poll on this that its not even close to 50-50; its more
> > > like 85-15. Luca raised this point during the last meeting, and it
> > > was evident from those in the room in Paris that there was a clear
> > > majority for the LDP-based solution. It might be true that
> > > the RSVP-TE-based solution gets implemented, but the question in
> > > my mind is who is actually going to *deploy and use* it? Following
> > > this argument, given its small potential for being deployed, would
> > > you ever need multiple vendors to interoperate on that solution
> > > based on an IETF standard? And should the IETF spend essentially
> > > equal WG resources developing such a solution?
> > >
> > >       I say we stop wasting the WG's resources and move
> > > forward on making the solution supported by the clear majority
> > > as solid and complete as possible.
> > >
> > >       --Tom
> > >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 17 Nov 2005 16:26:14 -0500

> Shah, Himanshu
> Sent: Thursday, November 17, 2005 3:50 PM
> To: Gray, Eric; Andrew G. Malis; Drake, John E
> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
> The reality is that the show of hands at these meetings 
> is hardly a good measure of true consensus. It only shows
> which companies were able to send how many people to 
> attend such meetings.
> 
> I am not a supporter of two solutions. As a co-author of
> LDP based solution, I was surprised that Dave McDyson (MCI), 
> another co-author of LDP based solution, spoke in favor of 
> progressing 
> RSVP based solution for now. Talking to other SPs in the hallway
> yielded the same feedback.
> 
> So I think we should leave the 'consensus' discussions for now
> and pick up on merit of each solution again.
> 
> To that end, I would like to hear from proponents of RSVP based
> solution 
> 1) to respond to Luca's technical question about the 
>    overlapping addresses. 
> 2) Is RSVP based solution limited to MS-PW? I know technically
>    it can be made to work for SS-PW. However, as far as deployments
>    are concerned would SPs deploy SS-PW using both LDP and RSVP?
>    What is the positioning from RSVP camp?

Himanshu,

Of course, RSVP_TU would work for single-hop PWs. Furthermore, RSVP-TE works for optical networks, SHD networks, MPLS networks and Ethernet networks (if GELS becomes a reality). It is obviously the protocol of choice for connection setup. It amazes me that the LDP camp wants to progress a solution that ONLY works for PWs.

Peter

> etc, etc..
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Gray, Eric
> > Sent: Thursday, November 17, 2005 3:01 PM
> > To: 'Andrew G. Malis'; Drake, John E
> > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 17 Nov 2005 17:17:27 -0500

Hi Peter,

Perhaps you should have made that case when SS-PW 
with LDP was being standardized. 

I did not ask if RSVP-TE would work for SS-PW.
That I know. I asked for positioning, given that
there are deployed LDP based solution for SS-PW.
How much messy should we make?

Also, remember, the number of PWs are orders of magnitude
higher than the number of LSPs. But before we get into
scalability discussions why don't we discuss other technical
issues..

/himanshu

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Thursday, November 17, 2005 4:26 PM
> To: Shah, Himanshu; Gray, Eric; Andrew G. Malis; Drake, John E
> Of course, RSVP_TU would work for single-hop PWs. 
> Furthermore, RSVP-TE works for optical networks, SHD 
> networks, MPLS networks and Ethernet networks (if GELS 
> becomes a reality). It is obviously the protocol of choice 
> for connection setup. It amazes me that the LDP camp wants to 
> progress a solution that ONLY works for PWs.
> 
> Peter
> 
> > 
> > etc, etc..
> > 
> > /himanshu
> >

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 17 Nov 2005 20:22:51 -0200

Himanshu,

	We could all wish for 20-20 foresight. But - as the saying
goes - if wishes were horses, we would all be hip deep in it.

	I assume that - when you say "the number of PWs are orders 
of magnitude higher than the number of LSPs" you're comparing a
present number of LSPs to a future number of PWs - is that right?

--
Eric  

--> -----Original Message-----
--> From: Shah, Himanshu [mailto:[email-masked]] 
--> Sent: Thursday, November 17, 2005 5:17 PM
--> To: Busschbach, Peter B (Peter); Gray, Eric; Andrew G. 
--> Malis; Drake, John E
--> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
--> Subject: RE: [PWE3] Inter-op is not necessary
--> 
--> Hi Peter,
--> 
--> Perhaps you should have made that case when SS-PW with LDP 
--> was being standardized. 
--> 
--> I did not ask if RSVP-TE would work for SS-PW.
--> That I know. I asked for positioning, given that there are 
--> deployed LDP based solution for SS-PW.
--> How much messy should we make?
--> 
--> Also, remember, the number of PWs are orders of magnitude 
--> higher than the number of LSPs. But before we get into 
--> scalability discussions why don't we discuss other 
--> technical issues..
--> 
--> /himanshu
--> 
--> > -----Original Message-----
--> > From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
--> > Sent: Thursday, November 17, 2005 4:26 PM
--> > To: Shah, Himanshu; Gray, Eric; Andrew G. Malis; Drake, John E
--> > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
--> > Subject: RE: [PWE3] Inter-op is not necessary
--> > 
--> > 
--> > 
--> > 
--> > > -----Original Message-----
--> > > From: [email-masked]
--> > [mailto:[email-masked]]On Behalf Of
--> > > Shah, Himanshu
--> > > Sent: Thursday, November 17, 2005 3:50 PM
--> > > To: Gray, Eric; Andrew G. Malis; Drake, John E
--> > > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
--> > > Subject: RE: [PWE3] Inter-op is not necessary
--> > > 
--> > > 
--> > > The reality is that the show of hands at these meetings 
--> is hardly a 
--> > > good measure of true consensus. It only shows which 
--> companies were 
--> > > able to send how many people to attend such meetings.
--> > > 
--> > > I am not a supporter of two solutions. As a co-author 
--> of LDP based 
--> > > solution, I was surprised that Dave McDyson (MCI), 
--> another co-author 
--> > > of LDP based solution, spoke in favor of progressing RSVP based 
--> > > solution for now. Talking to other SPs in the hallway 
--> yielded the 
--> > > same feedback.
--> > > 
--> > > So I think we should leave the 'consensus' discussions 
--> for now and 
--> > > pick up on merit of each solution again.
--> > > 
--> > > To that end, I would like to hear from proponents of RSVP based 
--> > > solution
--> > > 1) to respond to Luca's technical question about the 
--> > >    overlapping addresses. 
--> > > 2) Is RSVP based solution limited to MS-PW? I know technically
--> > >    it can be made to work for SS-PW. However, as far as 
--> deployments
--> > >    are concerned would SPs deploy SS-PW using both LDP and RSVP?
--> > >    What is the positioning from RSVP camp?
--> > 
--> > Himanshu,
--> > 
--> > Of course, RSVP_TU would work for single-hop PWs. 
--> > Furthermore, RSVP-TE works for optical networks, SHD 
--> networks, MPLS 
--> > networks and Ethernet networks (if GELS becomes a reality). It is 
--> > obviously the protocol of choice for connection setup. It 
--> amazes me 
--> > that the LDP camp wants to progress a solution that ONLY 
--> works for 
--> > PWs.
--> > 
--> > Peter
--> > 
--> > > 
--> > > etc, etc..
--> > > 
--> > > /himanshu
--> > > 
--> > > > -----Original Message-----
--> > > > From: [email-masked]
--> > > [mailto:[email-masked]]On Behalf Of
--> > > > Gray, Eric
--> > > > Sent: Thursday, November 17, 2005 3:01 PM
--> > > > To: 'Andrew G. Malis'; Drake, John E
--> > > > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; 
--> Mark Townsley
--> > > > Subject: RE: [PWE3] Inter-op is not necessary
--> > > > 
--> > > > 
--> > > > Andy,
--> > > > 
--> > > > 	That's not how I recall the discussion at all, 
--> and that is 
--> > > > because the minutes fail to capture the actual results.
--> > > > 
--> > > > 	As I recall, there was a lot of hands to accept 
--> each draft as a 
--> > > > working group document.  What was different was that 
--> for the LDP 
--> > > > version there were no objections while for the 
--> RSVP-TE version 
--> > > > there were a few.
--> > > > 
--> > > > 	This is one of the failings of our present 
--> basis for "consensus 
--> > > > shaving" in the IETF.  Whether or a minority is in 
--> the way of a 
--> > > > "rough consensus" depends a lot on who is playing the part of 
--> > > > "barber".
--> > > > 
--> > > > 	Where the issue may have become confusing was 
--> when it was pointed 
--> > > > out (by several people) that this was equivalent to 
--> indicating 
--> > > > that both proposals should become WG drafts and that 
--> would mean 
--> > > > extra work to advance both through the IETF, most 
--> people were - 
--> > > > stated mildly - not in favor of that.
--> > > > 
--> > > > 	Subsequent efforts to determine what that 
--> "state of confusion" 
--> > > > boiled down to were inconclusive.  That does not mean 
--> that anyone 
--> > > > is free to provide their personal spin as to what we 
--> concluded at 
--> > > > that meeting. The only determination That is 
--> legitimate is that we 
--> > > > determined nothing.
--> > > > 
--> > > > --
--> > > > Eric
--> > > > 
--> > > > --> -----Original Message-----
--> > > > --> From: [email-masked] 
--> [mailto:[email-masked]] On 
--> > > > --> Behalf Of Andrew G. Malis
--> > > > --> Sent: Thursday, November 17, 2005 2:28 PM
--> > > > --> To: Drake, John E
--> > > > --> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked];
--> > Mark Townsley
--> > > > --> Subject: RE: [PWE3] Inter-op is not necessary
--> > > > --> 
--> > > > --> John,
--> > > > --> 
--> > > > --> This is quoting from the minutes:
--> > > > --> 
--> > > > --> Dynamic Multi-Segment Pseudo Wire Signaling 
--> Procedures Using 
--> > > > --> LDP Florin Balus ([email-masked]) 
--> > > > --> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt
--> > > > --> ....
--> > > > --> Stewart Bryant: Who thinks this should be a WG 
--> draft: Large 
--> > > > --> number in favour
--> > > > --> 
--> > > > --> Setup and Maintenance of Pseudowires using 
--> RSVP-TE Dimitri 
--> > > > --> Papadimitriou draft-raggarwa-rsvpte-pw-02.txt .....
--> > > > --> Stewart Bryant: Is there consensus to make this a WG
--> > > > draft?: a few. 
--> > > > --> Will ask the question to the list.
--> > > > --> 
--> > > > --> 
--> > > > --> The minutes also reflect what I saw at the meeting.
--> > > > --> 
--> > > > --> Cheers,
--> > > > --> Andy
--> > > > --> 
--> > > > --> ---------
--> > > > --> 
--> > > > --> At 11/17/2005 10:55 -0800, Drake, John E wrote:
--> > > > --> >Tom,
--> > > > --> >
--> > > > --> >I don't think you and Luca should be judging consensus,
--> > > > --> but since you
--> > > > --> >are, I would say that the consensus in the Vancouver
--> > > > --> meeting seemed to
--> > > > --> >be overwhelmingly in favor of advancing both.
--> > > > --> >
--> > > > --> >Thanks,
--> > > > --> >
--> > > > --> >John
--> > > > --> >
--> > > > --> > > -----Original Message-----
--> > > > --> > > From: Thomas D. Nadeau [mailto:[email-masked]]
--> > > > --> > > Sent: Thursday, November 17, 2005 7:36 AM
--> > > > --> > > To: Mark Townsley
--> > > > --> > > Cc: Yaakov Stein; [email-masked]
--> > > > --> > > Subject: Re: [PWE3] Inter-op is not necessary
--> > > > --> > >
--> > > > --> > >
--> > > > --> > > > LE ROUX Jean-Louis RD-CORE-LAN wrote:
--> > > > --> > > >
--> > > > --> > > >> Hi Andrew,
--> > > > --> > > >>
--> > > > --> > > >>
--> > > > --> > > >>> I'm not a fan of "let the market decide" 
--> because in
--> > > > --> the end, as
--> > > > --> > > >>> a vendor you have to do both -
--> > > > --> > > >>
--> > > > --> > > >> Look at the RSVP-TE vs CR-LDP case, this is a good
--> > > > --> example, a bit
--> > > > --> > > >> related to our case here by the way:-), were the
--> > > > --> market decided,
--> > > > --> > > >> and it seems to me that not many vendors
--> > > > implemented both...
--> > > > --> > > >>
--> > > > --> > > > Ironically, the more split the WG is, the more
--> > > > --> important it is to
--> > > > --> > > > pick one path forward now. The closer we are to a
--> > > > --> 50/50 split, the
--> > > > --> > > > more likely everyone will end up implementing both,
--> > > > --> as well as the
--> > > > --> > > > interop between each given the interprovider
--> > > > --> requirements. This
--> > > > --> > > > additional overhead to interoperability only serves
--> > > > --> to inhibit
--> > > > --> > > > market forces.
--> > > > --> > >
--> > > > --> > >       I think its clear from the 2 or 3 times we have
--> > > > --> taken a poll
--> > > > --> > > on this that its not even close to 50-50; its 
--> more like
--> > > > --> 85-15. Luca
--> > > > --> > > raised this point during the last meeting, and it was
--> > > > --> evident from
--> > > > --> > > those in the room in Paris that there was a clear
--> > > > --> majority for the
--> > > > --> > > LDP-based solution. It might be true that the
--> > > > --> RSVP-TE-based solution
--> > > > --> > > gets implemented, but the question in my mind 
--> is who is
--> > > > --> actually
--> > > > --> > > going to *deploy and use* it? Following this argument,
--> > > > --> given its
--> > > > --> > > small potential for being deployed, would you 
--> ever need
--> > > > --> multiple
--> > > > --> > > vendors to interoperate on that solution based on an
--> > > > --> IETF standard? 
--> > > > --> > > And should the IETF spend essentially equal WG
--> > > > --> resources developing
--> > > > --> > > such a solution?
--> > > > --> > >
--> > > > --> > >       I say we stop wasting the WG's 
--> resources and move
--> > > > --> forward on
--> > > > --> > > making the solution supported by the clear majority as
--> > > > --> solid and
--> > > > --> > > complete as possible.
--> > > > --> > >
--> > > > --> > >       --Tom
--> > > > --> > >
--> > > > --> 
--> > > > --> 
--> > > > --> _______________________________________________
--> > > > --> pwe3 mailing list
--> > > > --> [email-masked]
--> > > > --> https://www1.ietf.org/mailman/listinfo/pwe3
--> > > > --> 
--> > > > 
--> > > > _______________________________________________
--> > > > 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: "Shah, Himanshu" <[email-masked]>
Date: Thu, 17 Nov 2005 17:31:03 -0500

Yes. PWs are multiplexed over transport LSPs.
As PWs get deployed in a PSN, across PSNs, the
number of PWs, would leapfrog LSPs (in my opinion).

I should not have brought in the scalability discussions though.
Anybody care to address the overlapping address issues Luca
asked?? ..:-)

/himanshu

> From: Gray, Eric [mailto:[email-masked]]
> Sent: Thursday, November 17, 2005 5:23 PM
> To: Shah, Himanshu
> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley;
> Busschbach, Peter B (Peter); Andrew G. Malis; Drake, John E

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 17 Nov 2005 17:38:12 -0500

Himanshu,

I thought Luca asked a question about PE/AC addressing in general. I don't recall that he identified an issue with overlapping addresses. Could you clarify when the problem of overlapping addresses occurs?

Peter

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Thursday, November 17, 2005 5:31 PM
> To: Gray, Eric

---

From: "Gray, Eric" <[email-masked]>
Date: Fri, 18 Nov 2005 16:09:15 -0200

Mark,

	I agree that the working group must address the issues of
co-existence, but the process initiated during the earlier MPLS
fiasco of requiring each protocol proposal to address this in
the proposal itself is clearly a recipe for delay. Given the
well-known experiences of this earlier debacle, insisting on a
similar process in this case MUST be viewed as intentionally
obstructive, unless someone first establishes incontravertible
proof that no other approach will suffice.

	One approach that has clearly worked in the past is for
a working group to take the task of defining "coexistence" on
as a separate task (in particular, a separate document).  Even
if we decide that the other documents cannot proceed beyond a
certain point (ID, Proposed Standard, etc.) until the work on
"coexistence" is complete, this approach _at_least_ makes it
possible complete two separate protocol proposals without either
one - deliberately or inadvertently - being used to deny progress
to the other.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Mark Townsley
--> Sent: Friday, November 18, 2005 9:20 AM
--> To: David McDysan
--> Cc: [email-masked]
--> Subject: Re: [PWE3] Inter-op is not necessary
--> 
--> David McDysan wrote:
--> 
--> >IMO, we already have a "l3vpn 25457bis option" a 
--> capability with single 
--> >segment PWs. In other contexts (e.g., FR, ATM), this has 
--> >interconnection case has been called a "back-to-back UNI." 
--> Since there 
--> >is no alternate path in such back-to-back SS-PWs, this is not an 
--> >acceptable solution from a service provider point of view. 
--> This is why 
--> >service providers and others have created the requirements in 
--> >http://ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requi
--> rements-01.txt.
--> >
--> >For these reasons, I believe that "co-existence" as 
--> defined in this 
--> >note is a not a MS-PW requirement.
--> >  
--> >
--> 
--> "Coexistance" is simply a word I made up to mean that if 
--> the WG decides to advance two proposals, it must recognize 
--> that both exist and what it is going to do about it. It 
--> isn't an MS or Provider requirement, it is a Working Group 
--> requirement. The WG MUST adequately address all of the 
--> complexities of advancing more than one solution if it 
--> decides to do so.
--> 
--> Dealing with this reality of coexistance will require the 
--> working group to define mechanisms based on MS-PW 
--> requirements. You have stated that interworking with SS-PWs 
--> is one such requirement. I agree, so in our minds if two 
--> proposals advance, then the WG will have to define 
--> interworking mechanisms between SS-LDP and MS-LDP as well 
--> as SS-LDP and MS-RSVP. Interworking between MS-LDP and 
--> MS-RSVP will depend on whether interoperating providers are 
--> willing to either (1) support both signalling types in 
--> their network, or (2) agree to peer only with those 
--> providers who choose their preferred protocol. You can't 
--> have both without interworking between the two.
--> 
--> - Mark
--> 
--> >This
--> >
--> >Dave
--> >
--> >  
--> >
--> >>-----Original Message-----
--> >>From: [email-masked] 
--> [mailto:[email-masked]] On Behalf 
--> >>Of Mark Townsley
--> >>Sent: Thursday, November 10, 2005 10:12 PM
--> >>To: Andy Li
--> >>Cc: [email-masked]
--> >>Subject: Re: [PWE3] Inter-op is not necessary
--> >>
--> >>
--> >>To be clear, I said that "coexistance" was a necessity to be 
--> >>documented by the WG. Whether coexistance equates to interworking 
--> >>depends on the MS requirements.
--> >>
--> >>If the WG decides that providers would rather operate in 
--> a "10a" model 
--> >>(to use l3vpn terminology) rather than switch directly 
--> from one PW to 
--> >>another, coexistance is possible without interworking 
--> between LDP and 
--> >>RSVP. If this is true, however, it does beg the question 
--> as to whether 
--> >>interprovider MS is truly necessary at all.
--> >>    
--> >>
--> >>- Mark
--> >>
--> >>Andy Li wrote:
--> >>
--> >>    
--> >>
--> >>>Hi,
--> >>>
--> >>> I don't think it is necessary to have both signaling 
--> mechanism for 
--> >>>MS-PW inter-op with each other. If two providers agree 
--> to peer with 
--> >>>each other to provide PW services, it will be a bonus if 
--> >>>      
--> >>>
--> >>they two use 
--> >>    
--> >>
--> >>>the same mechanism to set up PW circuits. If not, the business 
--> >>>interests will encourage them to stitch the PW circuits by using 
--> >>>back2back logical/virtual interface(s) or even a jumper 
--> >>>      
--> >>>
--> >>fiber between 
--> >>    
--> >>
--> >>>ODF.
--> >>>
--> >>> Therefore, out of my own opinion, the inter-op requirement 
--> >>>      
--> >>>
--> >>should be removed.
--> >>    
--> >>
--> >>>Best
--> >>>Andy Li
--> >>>
--> >>>_______________________________________________
--> >>>pwe3 mailing list
--> >>>[email-masked]
--> >>>https://www1.ietf.org/mailman/listinfo/pwe3
--> >>>
--> >>> 
--> >>>
--> >>>      
--> >>>
--> >>_______________________________________________
--> >>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: "Serbest, Yetik" <[email-masked]>
Date: Fri, 18 Nov 2005 13:44:21 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Busschbach, Peter B (Peter)
Sent: Friday, November 18, 2005 1:06 PM
To: 'Shah, Himanshu'; Gray, Eric; Andrew G. Malis; Drake, John E
Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
Subject: RE: [PWE3] Inter-op is not necessary

The interop discussion has many facets. One of them seems to be the
notion that there are existing SS-PW devices supporting LDP, with which
any new solution must be able to interwork. 

The answer is easy: upgrade the legacy equipment with new software so
that it supports whatever solution is selected for MS-PWs. 

[Yetik] I wish it was.

However, from comments in the Vancouver meeting and on the mailing list,
I got the impression that that is not an acceptable view. Let's
therefore assume that there are existing SS-PW devices that can not be
upgraded and that have to operate as they exist today. Such devices
would not support the globally-unique AIIs that the balus-bocci-martini
draft requires for MS-PWs. Therefore, if a new device would have to
interface with one of these old, unupgradable devices, it would have to
know that it cannot use the MS-PW signaling protocol but that it would
have to fall back on LDP with the AIIs that exist today. Hence, from
this perspective it does not make any difference whether we select
RSVP-TE or CR-LDP for MS-PWs, the interoperability with legacy devices
is problematic in both cases.

Peter

> Sent: Thursday, November 17, 2005 5:17 PM
> To: Busschbach, Peter B (Peter); Gray, Eric; Andrew G. Malis; Drake,
> John E

---

From: "Gray, Eric" <[email-masked]>
Date: Fri, 18 Nov 2005 17:45:18 -0200

Ray,
 
    Perhaps reading the rest of Peter's original mail would lead you
to realize that that is not what he proposed service providers would
or should do...
 
--
E

  _____  

From: Ray Qiu [mailto:[email-masked]] 
Sent: Friday, November 18, 2005 2:43 PM
To: Busschbach, Peter B (Peter)
Cc: Shah, Himanshu; Gray, Eric; Andrew G. Malis; Drake, John E; Thomas D.
Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
Subject: Re: [PWE3] Inter-op is not necessary

A simple answer like "just upgrade your box" doesn't do any good for service
providers.  If a provider is providing LDP based SS-PWs today, they would
have to upgrade all their boxes and re-provision the SS-PW services when
MS-PW is introduced. This is not desirable.

--Ray

On 11/18/05, Busschbach, Peter B (Peter) <[email-masked]
<mailto:[email-masked]> > wrote: 

I plead guilty. But could you explain how a provider would look at it?

-----Original Message-----
From: Ray Qiu [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Friday, November 18, 2005 2:15 PM
To: Busschbach, Peter B (Peter)

Cc: Shah, Himanshu; Gray, Eric; Andrew G. Malis; Drake, John E; Thomas D.
Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ; Mark Townsley
Subject: Re: [PWE3] Inter-op is not necessary

It is so obvious that the answer came from a vendor not a provider.  

--Ray

On 11/18/05, Busschbach, Peter B (Peter) <  <mailto:[email-masked]>
[email-masked]> wrote: 

The interop discussion has many facets. One of them seems to be the notion
that there are existing SS-PW devices supporting LDP, with which any new
solution must be able to interwork.

The answer is easy: upgrade the legacy equipment with new software so that
it supports whatever solution is selected for MS-PWs. However, from comments
in the Vancouver meeting and on the mailing list, I got the impression that
that is not an acceptable view. Let's therefore assume that there are
existing SS-PW devices that can not be upgraded and that have to operate as
they exist today. Such devices would not support the globally-unique AIIs
that the balus-bocci-martini draft requires for MS-PWs. Therefore, if a new
device would have to interface with one of these old, unupgradable devices,
it would have to know that it cannot use the MS-PW signaling protocol but
that it would have to fall back on LDP with the AIIs that exist today.
Hence, from this perspective it does not make any difference whether we
select RSVP-TE or CR-LDP for MS-PWs, the interoperability with legacy
devices is problematic in both cases.

Peter

> From: Shah, Himanshu [mailto:[email-masked] <mailto:[email-masked]> ]
> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ;
Mark Townsley
> > From: Busschbach, Peter B (Peter) [mailto:[email-masked]
<mailto:[email-masked]> ]
> > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]>
; Mark Townsley
> > > From: [email-masked] <mailto:[email-masked]> 
> > [mailto:  <mailto:[email-masked]> [email-masked]]On Behalf
Of
> > > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]
<mailto:[email-masked]> ; Mark Townsley
> > > > From: [email-masked] <mailto:[email-masked]> 
> > > [mailto:[email-masked] <mailto:[email-masked]> ]On
Behalf Of
> > > > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]
<mailto:[email-masked]> ; Mark Townsley
> > > > --> From: [email-masked] <mailto:[email-masked]>
[mailto:  <mailto:[email-masked]> [email-masked]]
> > > > --> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]
<mailto:[email-masked]> ;
> > Mark Townsley
> > > > --> Using LDP Florin Balus ([email-masked]
<mailto:[email-masked]>  )
> > > > --> > > From: Thomas D. Nadeau [mailto:  <mailto:[email-masked]>
[email-masked]]
> > > > --> > > Cc: Yaakov Stein; [email-masked] <mailto:[email-masked]> 
> > > > --> [email-masked] <mailto:[email-masked]> 
<https://www1.ietf.org/mailman/listinfo/pwe3> 
> > > > [email-masked] <mailto:[email-masked]> 
<https://www1.ietf.org/mailman/listinfo/pwe3> 
> > > [email-masked] <mailto:[email-masked]> 
<https://www1.ietf.org/mailman/listinfo/pwe3> 

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 18 Nov 2005 16:55:09 -0500

Ray,
 
As Eric already observed, you may have missed my point. To summarize: If  interoperability requires interworking with existing devices without *any* modifications, it is not clear that enhancing LDP is any better than moving to RSVP-TE.
 
Peter

-----Original Message-----
From: Ray Qiu [mailto:[email-masked]]
Sent: Friday, November 18, 2005 2:43 PM
To: Busschbach, Peter B (Peter)
Cc: Shah, Himanshu; Gray, Eric; Andrew G. Malis; Drake, John E; Thomas D. Nadeau; Yaakov Stein; [email-masked]; Mark Townsley
Subject: Re: [PWE3] Inter-op is not necessary

A simple answer like "just upgrade your box" doesn't do any good for service providers.  If a provider is providing LDP based SS-PWs today, they would have to upgrade all their boxes and re-provision the SS-PW services when MS-PW is introduced. This is not desirable.

--Ray

On 11/18/05, Busschbach, Peter B (Peter) < [email-masked] <mailto:[email-masked]> > wrote: 

-----Original Message-----
From: Ray Qiu [mailto: [email-masked] <mailto:[email-masked]> ]
Sent: Friday, November 18, 2005 2:15 PM
To: Busschbach, Peter B (Peter)

Cc: Shah, Himanshu; Gray, Eric; Andrew G. Malis; Drake, John E; Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ; Mark Townsley
Subject: Re: [PWE3] Inter-op is not necessary

--Ray

On 11/18/05, Busschbach, Peter B (Peter) <  <mailto:[email-masked]> [email-masked]> wrote: 

The interop discussion has many facets. One of them seems to be the notion that there are existing SS-PW devices supporting LDP, with which any new solution must be able to interwork.

The answer is easy: upgrade the legacy equipment with new software so that it supports whatever solution is selected for MS-PWs. However, from comments in the Vancouver meeting and on the mailing list, I got the impression that that is not an acceptable view. Let's therefore assume that there are existing SS-PW devices that can not be upgraded and that have to operate as they exist today. Such devices would not support the globally-unique AIIs that the balus-bocci-martini draft requires for MS-PWs. Therefore, if a new device would have to interface with one of these old, unupgradable devices, it would have to know that it cannot use the MS-PW signaling protocol but that it would have to fall back on LDP with the AIIs that exist today. Hence, from this perspective it does not make any difference whether we select RSVP-TE or CR-LDP for MS-PWs, the interoperability with legacy devices is problematic in both cases.

Peter

> From: Shah, Himanshu [mailto: [email-masked] <mailto:[email-masked]> ]
> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ; Mark Townsley
> > From: Busschbach, Peter B (Peter) [mailto: [email-masked] <mailto:[email-masked]> ]
> > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ; Mark Townsley
> > [mailto:  <mailto:[email-masked]> [email-masked]]On Behalf Of
> > > Shah, Himanshu
> > > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ; Mark Townsley
> > > [mailto: [email-masked] <mailto:[email-masked]> ]On Behalf Of
> > > > Gray, Eric
> > > > Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked] <mailto:[email-masked]> ; Mark Townsley
> > > > --> From: [email-masked] <mailto:[email-masked]>  [mailto:  <mailto:[email-masked]> [email-masked]]
> > > > --> Cc: Thomas D. Nadeau; Yaakov Stein; [email-masked]  <mailto:[email-masked]> ;
> > Mark Townsley
> > > > --> Using LDP Florin Balus ( [email-masked] <mailto:[email-masked]>  )
> > > > --> > > From: Thomas D. Nadeau [mailto:  <mailto:[email-masked]> [email-masked]]
> > > > --> https://www1.ietf.org/mailman/listinfo/pwe3 <https://www1.ietf.org/mailman/listinfo/pwe3> 
> > > > -->
> > > >
> > > > https://www1.ietf.org/mailman/listinfo/pwe3  <https://www1.ietf.org/mailman/listinfo/pwe3> 
> > > >
> > >
> > > https://www1.ietf.org/mailman/listinfo/pwe3 <https://www1.ietf.org/mailman/listinfo/pwe3> 
> > >
> >
>

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 21 Nov 2005 15:13:33 +0200

Danny (and all),
Following your suggestion, I would like to sound my "preferences and
opinions" 
regarding protocols for setup of MS-PW on the list.

1. I strongly support the LDP-based approach to setup and maintenance of
MS-PWs
   for the following reasons:
   - it meets the requirements of specific MS-PW applications I am primarily

     dealing with (single- or, at most, dual-homed access devices acting as
T-PEs)
     without adding excessive complexity 
   - it simplifies backward compatibility with the already deployed SS-PWs
     (including interworking from FEC 128 to FEC 129). I agree with the 
     many people on this list who see backward compatibility with SS-PWs as
     a MUST requirement and suggest explicitly adding it to the MS-PW
     requirements draft (draft-ietf-pwe3-ms-pw-requirements-01.txt)
   - it also simplifies backward compatibility with statically stitched
MS-PWs
     (as per draft-ietf-pwe3-segmented-pw-01.txt).

   In other words, I see a well-defined and substantial application space
where
   MS-PWs would benefit from the LDP-based approach. Based on that, I
support
   adopting draft-balus-bocci-martini-dyn-ms-pwe3-00.txt as a WG document
NOW.

2. I consider existence of a valid application space for the RSVP-TE-based
approach 
   that is not covered by the LDP-based approach as neither proved nor
disproved at 
   this stage. Hence this approach should be, IMO, given "the benefit 
   of doubt". This said, the "burden of proof" (of existence of a distinct
meaningful 
   application state for this approach lies with its proponents and, IMHO,
includes: 
   - an expanded definition of the relevant application space with explicit
specification
     of problems that do not admit a solution with the LDP-based approach
   - a clear demonstration of these problems being addressed by the
RSVP-TE-based approach 
    (a list of references to multiple MPLS and CCAMP WG drafts would not be
enough)
   - specification of a reasonable "interworking" process between the two
protocols
     (because, IMO, the LDP-based approach will stay with us anyway),

   I see resolution of the issues listed above as A GATE for advancing the
work on 
   the RSVP-TE-based approach in the PWE3 WG.

3. I do not support attempts to resuscitate CR-LDP for setup 
   and maintenance of MS-PWs as an alternative to the RSVP-TE-based approach
   for the following reasons:
   - After being "suspended", CR-LDP has missed quite a few features that
     have been or developed or are being developed and deployed for RSVP-TE
   - AFAIK, there is no deployment experience with CR-LDP
   - CR-LDP has been only designed to operate in the DoD mode (see RFC 3212,
     Section 3 "Solution Overview") while all the LDP-based proposals for
     setup and maintenance of PWs require LDP operation in the DU mode.
     IMO this means that the backward compatibility problem between 
     the deployed SS-PW setup and maintenance mechanism and a CR-LDP-based
approach
     would not differ that much from that for an RSVP-TE-based approach.
   This does not mean that we should not use some applicable TLVs defined
   for CR-LDP, e.g., ER etc. But these TLVs are not the key protocol
element.

Hopefully these notes clarify my position.

Regards,
				Sasha

> From: Danny McPherson [mailto:[email-masked]]
> Sent: Saturday, November 19, 2005 12:34 AM
> To: pwe3
> Eric et al.,
> This is one of the primary reasons why true consensus should
> only be obtained via the mailing list - things are much easier
> qualified, quantified, and .. [re]verified.
> 
> Folks, I suggest we let what we each recollect pass and if you've
> not voiced your preference/opinions on the mailing list please
> consider this the place which you need to be heard.
> 
> Thanks!
> 
> -danny
> 
> 
> On Nov 18, 2005, at 10:28 AM, Gray, Eric wrote:
> 
> > Stewart,
> >
> > 	Your version below is pretty much aligned with mine except
> > for two points:
> >
> > 1) "significant difference" is not quantified (or quantifiable);
> >    a good many people raised hands in both of the two latter cases
> >    (more than 20 - possibly more than 30 - in both cases), so a
> >    "significant difference" might be as little as 25% in actual
> >    difference in numbers.  If we're going to treat this as a vote,
> >    then we need to count hands.
> > 2) you also asked if any one objected in both of the latter cases
> >    and no one objected in one case (MS-LDP) and a few did in the
> >    other case (MS-RSVP).
> >
> > I am certain that this is what Dimitri is referring to when he
> > said that "a few" was associated with a different question than
> > as is reported in the minutes.
> >
> > 	Also, I do not see how your recollection is different from
> > (or inconsistent with) John's interpretation.  The first question
> > (in your list of three below) was answered in a way that implies
> > a clear majority wanting to advance both.
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 21 Nov 2005 16:37:56 -0500

My re-vote is identical to what Andy states below
for each question.

I also believe that if for some reasons the WG decides
to proceed with both solutions, then we need to ask
another set of questions wrt co-existence/inter-operability.

/himanshu

> Andrew G. Malis
> Sent: Monday, November 21, 2005 4:26 PM
> To: Vach Kompella
> Cc: 'pwe3'
> Here is my revote:
> Q1. Are you in favor of moving MS-LDP forward as WG draft?
> A1. Yes, including interoperability with SS-LDP using FEC 128
> 
> Q2. Are you against moving MS-LDP forward?
> A2. No.
> 
> Q3. Are you in favor of moving MS-RSVP forward as WG draft?
> A3. No, unless there is a demonstrated requirement from the SPs that 
> absolutely cannot be satisfied using MS-LDP.
> 
> Q4. Are you against moving MS-RSVP forward?
> A4. Yes (see A3).
> 
> Q5. Are you in favor of a single solution?
> A5. Yes (see A3).
> 
> Cheers,
> Andy
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 22 Nov 2005 06:49:00 +0200

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

---

From: "Florin Balus" <[email-masked]>
Date: Tue, 22 Nov 2005 13:24:22 -0500

Ping,
Most of the discussion points below are not dependent in my opinion on
the signaling protocols: e.g. the definition/meaning of FEC128/FEC129
addressing is the same for both RSVP-TE/LDP. Same challenges apply also
for congestion, OAM stuff.
I don't see in any case anything below that should be a gating factor
for WG status.

See also in-line ... 

>From: Ping Pan [mailto:[email-masked]] 
>Sent: Tuesday, November 22, 2005 11:25 AM
>To: Balus, Florin [CAR:6955:EXCH]
>Cc: Vach Kompella; pwe3
>OK.
>Are we done with one vs. two protocols yet? ;-)
>
>OK, let's get back into the technical side of the LDP MS-PW. 
>There are a 
>number of issues we need to resolve:
>
>(1) FEC 128 interfacing with FEC 129: FEC128 will not go through 
>multi-hop (or PWid collision). So how would a 128 user signal through 
>the network?

We did include a section in our draft
(draft-balus-bocci-martini-dyn-ms-pwe3) on FEC128 interworking. We asked
for comments and are opened to any contributions here as you know.

>
>(2) AII format: AII-2 is good for MS. But we are going to use 
>it for all 
>other applications, we need to have a consistent AII format (Andy and 
>George: that ATM-AII and Frame-AII in MFA need to be compatible with 
>this, right? :-))
>

Again this is not related to the signaling protocol in my opinion: in
both cases we will need new addressing formats to address the MFA
scenarios. We did not see specific MS-PW requirements from Service
Providers on these scenarios. We did define though in our draft the
requirements for any new addressing (e.g. format, globally unicity) to
be compatible with our signaling procedures.   

>(3) QoS format: I don't care if it is RSVP-TE or CR-LDP (the operator 
>won't care neither), so let's decide one. If it is the RSVP-TE format 
>(IntServ Controlled Load format, by default), is there any way to deal 
>with tricolor, and preemption?

We did specify our choice of RSVP-TE based format for Quantity of
Service (BW) which seems to be priority one for Service Provider.

>
>(4) "Congestion Control": Any thoughts on the mapping of EXP bit in 
>MS-PW? This can be an issue if the PW's run through a trunk 
>without the 
>underlying LSP's. ;-)
>

Not sure I follow what you're saying here. Can you elaborate?

>(5) Redundancy: I have submitted a draft on this topic. No MS-PW in it 
>yet, but would that be a good starting point?
>
>(6) OAM and OAM interworking: How would it work? Actually, would 
>carriers allow the OAM packets going over the boundary of the network? 
>If I am a carrier, I probably will not allow some guys on 
>either end of 
>my network to run some performance monitoring tests. Then how 
>do we get 
>edge-to-edge OAM?
>
These are good questions for SPs and the answers should be considered
for the related section of the MS-PW Requirements draft.

>I think this is what I have.
>
>Thanks!
>
>- Ping
>
>
>Florin Balus wrote:
>> If a re-vote was needed my opinion would be identical with the one 
>> expressed by Vach below.
>> 
>> Still I don't think there is a need to ask a question on whether an 
>> LDP solution is required! The time has passed for that: LDP 
>is already 
>> implemented and deployed for SS-PWs. And the strong support 
>we saw for 
>> draft-balus-bocci-martini-dyn-ms-pwe3 during the WG meeting in 
>> Vancouver, with nobody against, seem to indicate people agree we 
>> should work on expanding the current SS-PW solution to cover MS-PWs.
>> 
>> So the question on the above draft should be asked in my opinion the 
>> same way as it was for the MS-PW architecture draft: e.g. " 
>... there 
>> was strong consensus to make it a WG draft .. Anybody against say so 
>> by the <date>..."
>> 
>> Florin
>> 
>> 
>>>Behalf Of Vach Kompella
>>>Sent: Monday, November 21, 2005 2:36 PM
>>>To: 'pwe3'
>>>I second Danny's call for re-judging consensus.
>>>
>>>So here is my re-vote:
>>>
>>>Q1. Are you in favor of moving MS-LDP forward as WG draft? A1. Favor 
>>>moving MS-LDP forward as WG draft
>>>  - need to have a section of interop with FEC 128
>>>
>>>Q3. Are you in favor of moving MS-RSVP forward as WG draft? A3. 
>>>Withhold judgment on MS-RSVP until these are visible:
>>> - provider support
>>> - app stmt in some rudimentary form
>>> - interop with FEC 128 (the dominant PW FEC type deployed)
>>>
>>>A4. Can't answer since I don't have A3.
>>>
>>>A5. Need to answer A3.  My preference would be to have a
>>>single solution.  However, without A3, it seems pointless to 
>>>continue this argument.  Having implemented FEC 128, I can see 
>>>how to implement some form of interop with FEC 129.  Not 
>>>having implemented any SS-RSVP, I don't see that as 
>>>straightforward with MS-RSVP and SS-LDP.  So the beginnings of 
>>>that interop description would be helpful.
>>>
>>>As for the broader question of interop between MS-LDP (which
>>>seems likely to move forward) and MS-RSVP (which may), can we 
>>>wait on that until after A3?
>>>
>>>Essentially, I don't want stuff gating MS-LDP.
>>>
>>>-Vach
>>>
>>>
>>>>From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>>>>Of Danny McPherson
>>>>Sent: Friday, November 18, 2005 2:34 PM
>>>>To: pwe3
>>>>This is one of the primary reasons why true consensus 
>should only be 
>>>>obtained via the mailing list - things are much easier qualified, 
>>>>quantified, and .. [re]verified.
>>>>
>>>>Folks, I suggest we let what we each recollect pass and if 
>you've not 
>>>>voiced your preference/opinions on the mailing list please consider 
>>>>this the place which you need to be heard.
>>>>
>>>>Thanks!
>>>>
>>>>-danny
>>>>
>>>>
>>>>>	Your version below is pretty much aligned with mine
>>>>
>>>>except for two
>>>>
>>>>>points:
>>>>>
>>>>>I am certain that this is what Dimitri is referring to 
>when he said 
>>>>>that "a few" was associated with a different question than as is 
>>>>>reported in the minutes.
>>>>>
>>>>>	Also, I do not see how your recollection is different from (or 
>>>>>inconsistent with) John's interpretation.  The first
>>>>
>>>>question (in your
>>>>
>>>>>list of three below) was answered in a way that implies a clear 
>>>>>majority wanting to advance both.
>>>>

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 23 Nov 2005 09:45:03 -0500

Stewart,

	I've yet to see any indication on this mailing list that
anyone disagrees with what Ray said.  In fact, it is so obvious
a statement that many have simply not bothered to repeat it.

	Of course backward compatibility and - at least potential
- migration mechanisms/strategies are required.  It is that sad
consideration that makes avoidance of a two-protocol solution
difficult.

	MS-PW needs to be backward compatible with SS-PW.  MS-TE
also needs to be backward compatible with SS-TE.  Compatibility
for SS-PW and MS-PW seems to argue for compatible extensions to 
LDP.  Compatibility for SS-TE and MS-TE (or TE and PCE) likewise
argues for compatible extensions to RSVP-TE.  So eventually we 
either end up with backward compatibility complexity or a two-
protocol solution.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Stewart Bryant
--> Sent: Wednesday, November 23, 2005 4:04 AM
--> To: Ray Qiu; pwe3
--> Subject: Re: [PWE3] Inter-op is not necessary
--> 
--> Well I work for a vendor, but I agree with Ray.
--> 
--> Requiring the upgrade of boxes built to the PWE3-WG SS-PW 
--> spec is not acceptable. We have to be backwards compatible 
--> with our phase-1 design.
--> 
--> - Stewart
--> 
--> 
--> Ray Qiu wrote:
--> 
--> > A simple answer like "just upgrade your box" doesn't do 
--> any good for 
--> > service providers.  If a provider is providing LDP based 
--> SS-PWs today, 
--> > they would have to upgrade all their boxes and 
--> re-provision the SS-PW 
--> > services when MS-PW is introduced. This is not desirable.
--> >
--> > --Ray
--> >
--> > On 11/18/05, Busschbach, Peter B (Peter) <[email-masked] 
--> > <mailto:[email-masked]>> wrote:
--> >
--> >     I plead guilty. But could you explain how a provider 
--> would look at it?
--> >      
--> >
--> >         -----Original Message-----
--> >         From: Ray Qiu [mailto:[email-masked]
--> >         <mailto:[email-masked]>]
--> >         Sent: Friday, November 18, 2005 2:15 PM
--> >         To: Busschbach, Peter B (Peter)
--> >         Cc: Shah, Himanshu; Gray, Eric; Andrew G. Malis; 
--> Drake, John
--> >         E; Thomas D. Nadeau; Yaakov Stein; [email-masked]
--> >         <mailto:[email-masked]>; Mark Townsley
--> >         Subject: Re: [PWE3] Inter-op is not necessary
--> >
--> >         It is so obvious that the answer came from a vendor not a
--> >         provider.  
--> >
--> >         --Ray
--> >
--> >         On 11/18/05, Busschbach, Peter B (Peter) <
--> >         [email-masked] 
--> <mailto:[email-masked]>> wrote:
--> >
--> >             The interop discussion has many facets. One 
--> of them seems
--> >             to be the notion that there are existing SS-PW devices
--> >             supporting LDP, with which any new solution 
--> must be able
--> >             to interwork.
--> >
--> >             The answer is easy: upgrade the legacy 
--> equipment with new
--> >             software so that it supports whatever 
--> solution is selected
--> >             for MS-PWs. 
--> >
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 23 Nov 2005 09:47:59 -0600

I would like to see some discussion on the following questions raised
for MS-RVP:
- Addressing
- Scalability
- Inter-operability with FEC128

For now, my votes are as follows:

YES

NO

ABSTAIN

ABSTAIN

YES

Thanks,
yetik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gray, Eric
Sent: Wednesday, November 23, 2005 8:45 AM
To: 'Stewart Bryant'
Cc: pwe3
Subject: RE: [PWE3] Inter-op is not necessary

Stewart,

--
Eric