Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**

[Stewart Bryant <stbryant at cisco.com>]

Yaakov Stein wrote:
> Danny and Sasha, 
>
> I will comment both on the charter and Sasha's comments.
>
> s/Frame Realy/Frame Relay/ and please add TDM to that line.
> Also s/pseudo-wire/pseudowire/ (I saw one left).
>
> What does "Switching ... ON the traditional service ..." mean today ?
> It obviously should not rule choosing the correct PW at a VPLS ingress
>   

This is from the original charter and was meant to rule out PWE3 
specifying things like ATM switches. I suggest that we leave it in and 
if we ever need to specify native service switching we can ask for a 
charter revision on a case by case basis.

> PE
> (although not defined in PWE3).
> I don't care if it rules out an ECMP mechanism peaking at the first
> nibble,
> since this is only referenced in PWE3, not defined.
> Does it rule out an S-PE choosing a path based on a label chosen by the
> T-PE
> after looking at the native header ?
>   
What we need is an abstract mapping between the native service that 
understands the structure of the service and provides information to the 
T-PE on how to map this to one or more PWs.
> Does it rule out a PW protection mechanism that emulates the native
> service's mechanism ?
>   
So how would you word the restriction so as to permit the operations 
that we need without chartering native service switching which we must 
put out of scope?
> "PWE3 will specify requirements for clock recovery ..."
> Actually, TICTOC is specifying requirements. What I think PWE needs to
> do
> is to support TICTOC efforts on the protocol side.
>
>   
The original point was to allow the TDM PE designers to feed 
requirements to TICTOC through the PWE3 WG, but I am sure that if they 
have anything to say they will turn up in TICTOC and say it :)

> I agree with Sasha that we should be the design authority for PW over
> MPLS issues.
> In particular, we should be able to block redefinition of PW
> functionality,
> such as the popping of the PW label while leaving the tunnel label that
> has been proposed.
> If this requires another logistics RFC, then we should write one.
>   
You mean the single label PW concept. That would need consensus in PWE3 
and MPLS WG before we could work on it.

> Regarding PWE security, the MPLS security document intentionally did not
> go into
> data plane issues for non-IP clients. This was left for PWE to handle.
> (I really should refresh the PWE-security drafts ...)
>
> "Publish requirements and specification for PW load-balancing
> mechanisms."
> Can we add "inverse multiplexing" to "load balancing" ?
> I am writing a draft on this now.
>
> "to support the applications of MPLS to transport networks"
> did you mean "the application (no s) of MPLS" ?
> If so, perhaps "to support MPLS-based transport networks" ?
>
> Did the group ever agree that P2MP PWs are a good idea ?
> I seem to recall that at the mike people agreed that there could be the
> need
> to transport P2MP services over MPLS, but that it was unsure how this
> mapped onto the PWE3 architecture. PWs are emulations of "wires" not
> "trees".
>   
Many wires are trees! Certainly pt-mp wires exist in the transport world 
and have done for many years.

Unless we specify pt-mp PWs we condemn our users  to  emulate pt-mp  
using a set of  pt-pt PWs. What is needed is  the ability to map a pt-mp 
service through a pt-mp PW and then onto a multicast PSN.
> It may be a better idea to define a non-IP MPLS client that is not a PW.
>   
How do you see this mapping work?

- Stewart


_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www.ietf.org/mailman/listinfo/pwe3