Folks, Please consider this the start of the WG Last Call for the PWE3 Requirements document. Comments on the draft should be sent to pwe3 <at> ietf.org, or the authors directly. The document can be obtained via: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-03.txt The last call ends Oct 15 <at> 12P GMT. Thanks! -danny
At IETF-54 it was agreed that a single PWE3 terminology document would be generated defining common terms. My understanding is that PWE3 authors would then remove these common terms from their drafts thereby removing any conflicting definitions. I have derived these terms from a combination of the protocol- layering draft and the framework draft. This has been posted as <draft-bryant-pwe3-terms-00.txt>. I plan to put out a revised version before IETF-55, that will include feedback received. Stewart
The list below represents the set of change requests received from pwe3 members wrt the CEP MIB. See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-00.txt The 3 requests below are not required to go in together. So reply with individual comments, if you would like. Also, feel free to reply with any new requests. If there is rough consensus (or absence of comment) on any of the following, the co-authors will submit a new version: cep-mib-01. ----------------------- 1) Support for SONET-VT emulation work underway in PWE3. This includes generalizing the main CEP table to handle single VT mode, and adding an optional table for configuring fractional SPE. See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-vt-00.txt 2) Support for RTP. Add an object to CEP config table (pwVcCepCfgTable) to specify whether RTP header is suppressed or not. This is per http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.txt 3) Remove "Jitter Buffer Rebuild" objects. Delete 2 objects from the CEP config table (pwVcCepCfgTable): pwVcCepCfgJtrBfrRebuildOor and pwVcCepCfgJtrBfrRebuildOorCount. Without additional objects, the feature intended via these 2 objects is not fully functional. Also, when considering that this feature is not part of the pwe3-sonet draft, these objects should be removed. See http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.txt
Some comments on <draft-ietf-pwe3-requirements-03.txt>
Stewart
<snip>
1.1. Reference Model of PWE3
A pseudo-wire (PW) is a connection between two provider edge (PE)
devices which connects two pseudo-wire end-services (PWESs) of the
same type. A PWES is either:
- an Ethernet link or a VLAN link between two ports, or
- an ATM VC or VP, or
- a Frame Relay VC, or
- a TDM circuit, or
- an MPLS LSP
SB> Why not raw HDLC frames?
SB> Do you mean TDM or something more generic? How does SONET fit in
SB> to this taxonomy?
between a customer edge (CE) device and a PE (See Figure 1). During
the setup of a PW, the two PEs will be configured or will
automatically exchange information about the service to be emulated
so that later they know how to process packets coming from the other
end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, Frame Relay
and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are
encapsulated at the PW ingress. The encapsulated PDUs are then sent
over the PW to the egress, where L2 or L1 headers are re-constructed
(Continue reading)
One comment inline.
>Some comments on <draft-ietf-pwe3-requirements-03.txt>
>
>Stewart
>
><snip>
>
>1.1. Reference Model of PWE3
>
> A pseudo-wire (PW) is a connection between two provider edge (PE)
> devices which connects two pseudo-wire end-services (PWESs) of the
> same type. A PWES is either:
> - an Ethernet link or a VLAN link between two ports, or
> - an ATM VC or VP, or
> - a Frame Relay VC, or
> - a TDM circuit, or
> - an MPLS LSP
>
>SB> Why not raw HDLC frames?
>SB> Do you mean TDM or something more generic? How does SONET fit in
>SB> to this taxonomy?
>
> between a customer edge (CE) device and a PE (See Figure 1). During
> the setup of a PW, the two PEs will be configured or will
> automatically exchange information about the service to be emulated
> so that later they know how to process packets coming from the other
> end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, Frame Relay
> and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are
(Continue reading)
Thomas D. Nadeau wrote: > >> >> 4.6. Pseudo-Wire Traceroute >> >> It can be desirable to know the exact path of a PW, especially for >> troubleshooting purpose. A PW emulation service MUST support PW >> traceroute. >> >> SB> Wow, you need to be very careful here. I think that if you >> SB> only have access to a TDM circuit, figuring how it got >> SB> across the PSN is pretty tough. It also breaks the transparancy >> SB> of the wire. This needs to be re-written or deleted. > > > Given the operational requirements that I have seen, > it is paramount for deployment of services to have a tracing/ping Trace or ping, which one do we care most about? They tend to have very different implementation requirements, and lumping them together at the same level of requirement may not be fully respecting this. > function before these folks will deploy PWs in their networks. > I would be okay to change "MUST" to "SHOULD" if that would > make you happy. > > --Tom
>> <snip> >> >> 4.6. Pseudo-Wire Traceroute >> >> It can be desirable to know the exact path of a PW, especially for >> troubleshooting purpose. A PW emulation service MUST support PW >> traceroute. >> >> SB> Wow, you need to be very careful here. I think that if you >> SB> only have access to a TDM circuit, figuring how it got >> SB> across the PSN is pretty tough. It also breaks the transparancy >> SB> of the wire. This needs to be re-written or deleted. > > > Given the operational requirements that I have seen, > it is paramount for deployment of services to have a tracing/ping > function before these folks will deploy PWs in their networks. > I would be okay to change "MUST" to "SHOULD" if that would > make you happy. > > --Tom > > > I would be fine with SHOULD. MUST means put the project on hold until we find a solution and depending on what you have in mind, it is not clear that we have such a solution on the horizon.(Continue reading)
Thomas D. Nadeau wrote 02 October 2002 20:40 <snipped> > >4.6. Pseudo-Wire Traceroute > > > > It can be desirable to know the exact path of a PW, > especially for > > troubleshooting purpose. A PW emulation service MUST support PW > > traceroute. > > > >SB> Wow, you need to be very careful here. I think that if you > >SB> only have access to a TDM circuit, figuring how it got > >SB> across the PSN is pretty tough. It also breaks the transparancy > >SB> of the wire. This needs to be re-written or deleted. > > Given the operational requirements that I have seen, > it is paramount for deployment of services to have a tracing/ping > function before these folks will deploy PWs in their networks. > I would be okay to change "MUST" to "SHOULD" if that would > make you happy. NH=> The operations requirements don't specifically ask for trace-route or LSP-Ping.....that is your interpretation. Operations people now want to able to manage the technoloogy they have been sold that came without any such fault-management tools. The p2p case of LSPs is trivally solved with Y.1711...and you cannot get any simpler than that as you ought to know. LDP is the problem.....though what real *operators network problem* LDP solves that is not better solved by a pure IP solution beats me...I have asked this question loads of times and I can't find anyone who can answer it. However, given the nature of the beast and that its out there, I would not want to preclude other solutions for the network management headaches LDP mp2p(Continue reading)
At 08:03 AM 10/3/2002 +0200, W. Mark Townsley wrote:
>Thomas D. Nadeau wrote:
>>
>>>
>>>4.6. Pseudo-Wire Traceroute
>>>
>>> It can be desirable to know the exact path of a PW, especially for
>>> troubleshooting purpose. A PW emulation service MUST support PW
>>> traceroute.
>>>
>>>SB> Wow, you need to be very careful here. I think that if you
>>>SB> only have access to a TDM circuit, figuring how it got
>>>SB> across the PSN is pretty tough. It also breaks the transparancy
>>>SB> of the wire. This needs to be re-written or deleted.
>>
>> Given the operational requirements that I have seen,
>>it is paramount for deployment of services to have a tracing/ping
>
>Trace or ping, which one do we care most about? They tend to have very
>different implementation requirements, and lumping them together at the
>same level of requirement may not be fully respecting this.
Both are important, CV is important to detect failures and the
other (trace) to detect
where the failure occurred. Currently MPLS LSP ping integrates both, for
example. So,
I think that we can change the text to something like:
It can be desirable to verify the connection status between the edges
(Continue reading)
At 08:41 AM 10/3/2002 +0100, Stewart Bryant wrote: >>><snip> >>> >>>4.6. Pseudo-Wire Traceroute >>> >>> It can be desirable to know the exact path of a PW, especially for >>> troubleshooting purpose. A PW emulation service MUST support PW >>> traceroute. >>> >>>SB> Wow, you need to be very careful here. I think that if you >>>SB> only have access to a TDM circuit, figuring how it got >>>SB> across the PSN is pretty tough. It also breaks the transparancy >>>SB> of the wire. This needs to be re-written or deleted. >> >> Given the operational requirements that I have seen, >>it is paramount for deployment of services to have a tracing/ping >>function before these folks will deploy PWs in their networks. >>I would be okay to change "MUST" to "SHOULD" if that would >>make you happy. >> --Tom >> > >I would be fine with SHOULD. >MUST means put the project on hold until we find a solution >and depending on what you have in mind, it is not clear that >we have such a solution on the horizon. > >When you say "know the exact path", who should know the exact >path and from what point of view?(Continue reading)
RSS Feed3 | |
|---|---|
3 | |
10 | |
19 | |
17 | |
17 | |
67 | |
28 | |
33 | |
54 | |
60 | |
15 | |
59 | |
34 | |
29 | |
38 | |
50 | |
29 | |
43 | |
41 | |
84 | |
88 | |
81 | |
92 | |
22 | |
111 | |
97 | |
44 | |
20 | |
59 | |
139 | |
56 | |
54 | |
44 | |
193 | |
73 | |
33 | |
63 | |
74 | |
32 | |
25 | |
59 | |
94 | |
23 | |
34 | |
106 | |
62 | |
49 | |
36 | |
94 | |
86 | |
31 | |
25 | |
42 | |
68 | |
109 | |
27 | |
34 | |
205 | |
39 | |
47 | |
37 | |
20 | |
44 | |
121 | |
94 | |
44 | |
28 | |
44 | |
30 | |
40 | |
37 | |
54 | |
31 | |
178 | |
38 | |
88 | |
13 | |
43 | |
74 | |
22 | |
107 | |
90 | |
39 | |
76 | |
11 | |
49 | |
64 | |
81 | |
75 | |
222 | |
126 | |
62 | |
143 | |
246 | |
75 | |
63 | |
55 | |
316 | |
208 | |
45 | |
54 | |
106 | |
132 | |
159 | |
125 | |
143 | |
74 | |
65 | |
58 | |
151 | |
135 | |
47 | |
134 | |
224 | |
69 | |
132 | |
35 | |
86 | |
276 | |
328 | |
233 | |
248 | |
126 | |
23 | |
76 | |
171 | |
195 | |
137 | |
144 | |
179 | |
135 | |
254 | |
230 | |
1 |
