[PWE3] unsubscribe

["Jeff Atwood" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, March 22, 2007 6:12 PM
To: [e-mail]
Subject: pwe3 Digest, Vol 35, Issue 35

Send pwe3 mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/pwe3
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of pwe3 digest..."


Today's Topics:

   1. RE: Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt 
      (O'Connor, Don)
   2. RE: WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt  (Suberri, Moshe)


----------------------------------------------------------------------

Message: 1
Date: Thu, 22 Mar 2007 16:30:32 -0500
From: "O'Connor, Don" <[e-mail]>
Subject: RE: [PWE3] Fwd: I-D
	ACTION:draft-bryant-pwe3-mpls-transport-00.txt
To: "Thomas D. Nadeau" <[e-mail]>
Cc: Swallow George <[e-mail]>, [e-mail],	Danny McPherson
	<[e-mail]>, "pwe3
	
\(\(\(\(\(\(\(\(\(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\)\)\)\)\)\)\)\)\)
	WG" <[e-mail]>, Townsley Mark <[e-mail]>,	Ward
David
	<[e-mail]>
Message-ID:
	<[e-mail]>
Content-Type: text/plain;	charset="iso-8859-1"

Tom

Your reply below indicated that

"Perhaps. FYI, our draft, as-written supports both static and signaled paths
via GMPLS/RSVP-TE. From section 4.2:

	 In this section we describe the profile when RSVP-TE [] or the bi-
	 directional support in GMPLS [] are used to configure the MPLS PSN
	 used to provide the transport LSPs."

My initial comment was

"For example for Transport Multi-Segment Pseudowires the  
> preferred signaling solution could be GMPLS RSVP-TE rather than LDP"

This comment did not refer to signaling for the MPLS PSN (as in section
4.2). This comment suggested that maybe GMPLS RSVP-TE could be used for
Transport Pseudowire signaling for multi-segment transport pseudowires. 

Regards

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[e-mail]]
Sent: Thursday, March 22, 2007 3:50 PM
To: O'Connor, Don
Cc: Danny McPherson; pwe3 ((((((((((((((((E-mail)))))))))))))))) WG; Swallow
George; [e-mail]; Townsley Mark; Ward David; Ross Callon
Subject: Re: [PWE3] Fwd: I-D
ACTION:draft-bryant-pwe3-mpls-transport-00.txt 



On Mar 22, 2007:4:32 PM, at 4:32 PM, O'Connor, Don wrote:

> Tom,
>
> Please see my replies below
>
> Regards
>
> Don
>
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]]
> Sent: Thursday, March 22, 2007 1:00 PM
> To: O'Connor, Don
> Cc: Danny McPherson; pwe3 ((((((((((((((((E-mail)))))))))))))))) WG; 
> Swallow George; [e-mail]; Townsley Mark; Ward David; Ross Callon
> Subject: Re: [PWE3] Fwd: I-D
> ACTION:draft-bryant-pwe3-mpls-transport-00.txt
>
>
>
> 	Hi,
>
>> I do not support draft-bryant-pwe3-mpls-transport-00.txt as a WG 
>> draft for the following reasons
>>
>> 1) Transport MPLS as pursued by ITU encompasses functionality that 
>> overlaps work in multiple IETF WGs. A minimum subset is PWE3 and 
>> MPLS. Work in CCAMP is also most probably relevant. Without companion 
>> work in the MPLS WG on a T-MPLS implementation profile, 
>> draft-bryant-pwe3-mpls-transport-00.txt serves no useful purpose
>
> 	Although Townsley and Ross/Ward should declare which WGs are most 
> relevant for this draft, my two cents are that although PWE3 and MPLS 
> are surely relevant to the draft as-written, I don't see where CCAMP 
> (or any other WG) needs to be involved other than PWE3 since the 
> purpose of the draft is to show how the requirements for T-MPLS can be 
> solved using a few "off the shelf" and already deployed protocols.
>
> [Don - CCAMP involvement may not be needed in the near term, but my 
> view is that it would be needed in the longer term if a more 
> comprehensive relationship is developed between ITU SG 15 and IETF for 
> Transport MPLS standardization (including the Control Plane aspects). 
> For example for Transport Multi-Segment Pseudowires the preferred 
> signaling solution could be GMPLS RSVP-TE rather than LDP]

	Perhaps. FYI, our draft, as-written supports both static and
signaled paths via GMPLS/RSVP-TE. From section 4.2:

	 In this section we describe the profile when RSVP-TE [] or the bi-
	 directional support in GMPLS [] are used to configure the MPLS PSN
	 used to provide the transport LSPs.

>> I suggest that a first necessary step is that the appropriate Area 
>> Directors consider whether or not they want to take on the entire 
>> task of generating a complete Transport MPLS implementation profile 
>> based on current RFC / ID / extensions and doing it right and 
>> comprehensively. WG charters should be updated appropriately
>
> 	Why do charters need to be updated? If you have read the draft, we 
> have shown how a "comprehensive T-MPLS solution" can be built only 
> using existing (and deployed) protocols.  What you are advocating is 
> slowing down the progress on this issue with needless procedural 
> process.
>
> [Don - My understanding is that the goals / perceived applications of 
> Transport MPLS go beyond the Ethernet Port connectivity scenario in 
> the existing draft. I think a longer term commitment is needed than 
> just the draft in question. Consequently a potential appropriate step 
> would be charter updates for PWE3 and MPLS WGs. As a near term minimum 
> I think the MPLS WG should agree to work on Transport MPLS RFCs. 
> Section 4 of the draft in question could be used as a starting basis 
> for an ID on Transport MPLS LSPs. My understanding is that ITU also 
> wishes to support P2MP Transport MPLS LSPs. So this would require an 
> implantation profile from the MPLS WG.]

	I still don't see why the charters need to be updated per se, except
perhaps to add milestones for these work items explicitly.
Whether or not that is necessary is again up to the chairs/ADs, but IMHO it
is unnecessary.

>> In its present form draft-bryant-pwe3-mpls-transport-00.txt is an 
>> incomplete attempt at addressing a portion of what ITU SG 15 and ITU 
>> SG 13 are pursuing for Transport MPLS
>
> 	Perhaps you could elaborate on this statement?
>
> [Don - I will offer several examples - Multi-Segment Transport 
> Pseudowires, protection switching as defined in G.8131, Transport MPLS 
> Ring Protection, OAM as defined in Y.17tor / Y.17tom, ID on Transport 
> MPLS LSPs including P2MP, Control Plane LDP per segmented PWs may not 
> be the appropriate solution]
>> If IETF leadership decides that they would like to pursue a 
>> comprehensive Transport MPLS implementation profile, it should be 
>> done in cooperation and coordination with leadership in ITU SG 15 and 
>> SG 13. I would support such as effort if it is done in this context. 
>> To date draft-bryant-pwe3-transport-00.txt does not fall into this 
>> category
>
> 	I think the point is that the IETF leadership has already decided to

> pursue T-MPLS by virtue of it being a true subset of MPLS/PWE3. I 
> don't see why any further procedural actions are necessary to move 
> this work forward.
>
> [Don - I think a more comprehensive longer term commitment is needed 
> beyond draft-bryant]
>
>> 2) draft-bryant-pwe3-mpls-transport-00.txt does not adequately 
>> address Transport MPLS OAM and Protection Switching requirements
>
> 	Please be specific.
>
> [Don - please see G.8131,G.8031, Y.17tor / Y.17tom]
>
>> 2A) Protection Switching - linear protection switching coordinated by 
>> an appropriate OAM protocol is required. It is necessary to meet the 
>> requirements of G.8131
>
> 	Please be specific.
>
> [Don - please see the detailed functionality in G.8131 and G.8031]
>
>> 2B) Current pseudowire VCCC OAM lacks - Maintenance Entity Levels, 
>> MEP / MIP, AIS / RDI, PM measurement. It is necessary to provide the 
>> functionality being developed for Y.17tom
>
> 	Although this is true, adding these is not difficult, and is 
> something that is already being discussed as part of the MH-VCCV work.
>
> [Don - One potential way to add the missing OAM functionality is
> to: 1) Allocate VCCV code points for "Y.1731 / 802.1ag for 
> pseudowires" and 2)modify Y.1731 / 802.1ag for use with VCCV (e.g.
> use AII rather than Ethernet SA / DA]

	Another is to modify y.17tom (which is a fantastic way to name a
document I might add!)  to reference y.1714.  We have in fact already made
recent contributions to do so. And of course, as I said, to add MIP/MEPs to
MH-VCCV.

	--Tom



>
> 	--Tom
>
>
>
>>
>> Regards
>>
>> Don
>>
>>
>> -----Original Message-----
>> From: Danny McPherson [mailto:[e-mail]]
>> Sent: Thursday, March 22, 2007 4:31 AM
>> To: pwe3 ((((((((E-mail)))))))) WG
>> Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls- 
>> transport-00.txt
>>
>>
>> 	
>> Folks,
>> As discussed in the meeting, I'd like to solicit WG feedback on
>> adopting this as a WG document.   If you're in favor or opposed
>> to adopting this please speak up now.
>>
>> -danny
>>
>>
>> Begin forwarded message:
>>
>>> From: [e-mail]
>>> Date: October 16, 2006 1:50:01 PM MDT
>>> To: [e-mail]
>>> Subject: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt
>>> Reply-To: [e-mail]
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>
>>>
>>> 	Title		: Application of PWE3 to MPLS Transport Networks
>>> 	Author(s)	: S. Bryant
>>> 	Filename	: draft-bryant-pwe3-mpls-transport-00.txt
>>> 	Pages		: 13
>>> 	Date		: 2006-10-16
>>> 	
>>>   A need has been identified to identify a strict subset of the PWE3
>>>   over MPLS pseudowire functionality suitable for the construction 
>>> of
>>>   transport networks. This draft describes the IETF recommended 
>>> profile
>>>   for such cases. This document describes the IETF-recommended 
>>> profile
>>>   for such a configuration. In particular the profile of an RFC4448
>>>   PWE3 Ethernet pseudowire that can be used to address these
>>>   requirements is described.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-bryant-pwe3-mpls-
>>> transport-00.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to 
>>> [e-mail] with the word unsubscribe in the body 
>>> of the message.
>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
>>> announce
>>> to change your subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with the 
>>> username "anonymous" and a password of your e-mail address. After 
>>> logging in, type "cd internet-drafts" and then "get 
>>> draft-bryant-pwe3-mpls-transport-00.txt".
>>>
>>> A list of Internet-Drafts directories can be found in 
>>> http://www.ietf.org/shadow.html or 
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> 	[e-mail].
>>> In the body type:
>>> 	"FILE /internet-drafts/draft-bryant-pwe3-mpls-transport-00.txt".
>>> 	
>>> NOTE:	The mail server at ietf.org can return the document in
>>> 	MIME-encoded form by using the "mpack" utility.  To use this
>>> 	feature, insert the command "ENCODING mime" before the "FILE"
>>> 	command.  To decode the response(s), you will need "munpack" or
>>> 	a MIME-compliant mail reader.  Different MIME-compliant mail 
>>> readers
>>> 	exhibit different behavior, especially when dealing with
>>> 	"multipart" MIME messages (i.e. documents which have been split
>>> 	up into multiple messages), so check your local documentation on
>>> 	how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader 
>>> implementation to automatically retrieve the ASCII version of the 
>>> Internet-Draft.
>>> Content-Type: text/plain
>>> Content-ID: <[e-mail]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/pwe3



------------------------------

Message: 2
Date: Thu, 22 Mar 2007 19:12:20 -0400
From: "Suberri, Moshe" <[e-mail]>
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt
To: "Ronen Solomon" <[e-mail]>, "Orly Nicklass"
	<[e-mail]>,	"Thomas D. Nadeau" <[e-mail]>
Cc: [e-mail],	"pwe3 WG
	\(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\)" <[e-mail]>,
	[e-mail], Danny McPherson <[e-mail]>
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="us-ascii"

 

in lines

 

________________________________

From: Ronen Solomon [mailto:[e-mail]]
Sent: Wednesday, March 21, 2007 3:14 PM
To: Orly Nicklass; Thomas D. Nadeau
Cc: Danny McPherson; pwe3 WG ((((((((E-mail))))))));
[e-mail]; [e-mail]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

 

in line

 

________________________________

From: Orly Nicklass [mailto:[e-mail]]
Sent: Wednesday, March 21, 2007 12:00 AM
To: Ronen Solomon; Thomas D. Nadeau
Cc: [e-mail];
[e-mail]; pwe3 WG ((((((((E-mail)))))))); Danny
McPherson
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

in lines

________________________________

From: Ronen Solomon [mailto:[e-mail]]
Sent: Tue 3/20/2007 21:38
To: Thomas D. Nadeau
Cc: [e-mail];
[e-mail]; Orly Nicklass; pwe3 WG
((((((((E-mail)))))))); Danny McPherson
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 



-----Original Message-----
From: Thomas D. Nadeau [mailto:[e-mail] <mailto:[e-mail]>
]
Sent: Tuesday, March 20, 2007 5:26 PM
To: Ronen Solomon
Cc: [e-mail];
[e-mail]; Orly Nicklass; pwe3 WG
((((((((E-mail)))))))); Danny McPherson
Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt


On Mar 20, 2007:11:17 AM, at 11:17 AM, Ronen Solomon wrote:

> comments
>
> 1. Need to add a separate ATM transparent cell mode table 
> configuration as VPI and VCI are not applicable rather then use the 
> existing VPI/VCI 1:N tables. The current MIB uses the VPI/VCI tables 
> with 0xFFFFFF which is not adequate for a management system.

        Please make specific suggestions.  This will speed the process
along, and also allow the WG to comment on the specifics of what you are
asking.
-----------------------------------------
pwAtmTable index by pwIndex

"This table specifies the information for an ATM PW to
          be carried over PSN. An entry is created in this table for every
entry in
          the pwTable with a pwType equal to type 0x0003, ATM transparent
cell transport
          ."

PwAtmEntry ::= SEQUENCE {
    PwAtmIndex                                    RowPointer,
    PwAtmIfIndex                                   InterfaceIndex,
    pwAtmOutboundTrafficParamDescr    RowPointer,
    pwAtmInboundTrafficParamDescr       RowPointer
    pwAtmRowStatus                             RowStatus
}

Row status is used to modify an entry.
[ON] the idea was to use the existing tables with the same model for all
three modes and not have a table per mode. 1:1 table stays for backward
compatibility,   the n:1 can serve them all. Having single table for all
applicable modes indeed help the nms. I rather leave this part as is [Ronen
Solomon] I suggest you re-consider this so that the MIB would be useful for
NMS (this is what it is supposed to do). The port-mode is a bi-directional
direction (and The port mode would is very useful for metro equipment that
aggregate ATM switches), and does not require separation for inbound and
outbound. There is no meaning to have this complexity for a simple port-node
scenario. 

 

[Moshe] I can certainly appreciate the point of having one table for all
modes, and the point of having more flexible addressing of the traffic flow.
Will using an 'address type' concept in the current tables will solve this
issue?  

-----------------------------------------------------------
> 2. pwAtmCfgFarEndMaxCellConcatenation should also be used as a 
> read-write object if LDP is not used. The reason is that this 
> parameter should allow the local node to calculate protocol overhead 
> at the egress direction of the PW (i.e. direction from the remote PE 
> to the local PE).

        OK.
[ON] we can do that but leave the write op as optional.


> 3. pwAtmCfgTimeoutMode should be configurable timer. Different 
> application requires different timeouts such as AAL1 requires 
> different timeout then AAL2 data traffic. If HW does not support such 
> functionality then a default vlaue should  be applied.

        OK.

[ON] Time out can be set per PW or at system level, since it is
implementation specific, we use en/dis only and leave the actual time value
to be in private space. In addition, en/dis allows sparing the timeout value
and controlling it externally.
[Ronen Solomon] This is a mandatory object in live operation of ATM
(ALL1 and ALL2 must have different timeout timers), and therefore should be
supported. Hence i believe it should appear as a standard MIB. If HW does
not support such configuration it could set a default parameter.  

I like to get additional opinion here before we change it or add the actual
time value as an additional object or leave it as is.

----------------------------
We may have the current parameter foir enable/diable and when enabled
the following configured the timeout with a DEFVAL.   

pwAtmCfgTimeout
SYNTAX  Unsigned32 (100..10000)
    UNITS   "microseconds"
    MAX-ACCESS read-write
    STATUS  current
    DESCRIPTION
        ""
    DEFVAL { 100 }

------------------------------------------


> 4. Suggested to ATM PW Outbound Perf Table a new parameter "Average 
> concatenated cells" , which will allow the operator the analyze what 
> is the average number of cells that are concatenated into a single 
> frame.
> This has influence on bandwidth usage due to protocol overhead.

        I do not like this object, at least as a mandatory one, as it is
largely dependent on the local node computing this average.
I would rather than the NMS do this based on gathering statistics given that
some of the PW hardware being used is quite low-end, and the CPUs are close
to %100 dedicated for packet forwarding.

[ON] I rather see the NMS handle such.
[Ronen Solomon] Can you suggest a method , how would an NMS perform such
function ? It would require history data or some kind of histogram PMs.
It is much simpler and more efficient for the agent to calculate a moving
average, rather an NMS calculation together with history PMs
gathered by the agent.   
--------------------------------

I can suggest a simple moving averaging (w/o history data or CPU
intensive) method  ==> 

AvergaeN[i] = (1-X) * AvergaeN[i-1] + (X) * CurrentN[i] where X is
implementation specific with value of 0<X<1.

----------------------------------------
Ronen

        --Tom


>
> Ronen
>
>
>
>
> -----Original Message-----
> From: Danny McPherson [mailto:[e-mail] <mailto:[e-mail]> ]
> Sent: Monday, March 05, 2007 7:24 AM
> To: pwe3 WG ((((((((E-mail))))))))
> Subject: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt
>
>      
> Folks,
> Please consider today the beginning of a 3 week WG last call for this 
> document.  Please direct any comments with this revision of the draft 
> to the authors and PWE3 mailing list.
>
> Thanks!
>
> -danny & Stewart
>
>
> Begin forwarded message:
>
>> From: [e-mail]
>> Date: February 13, 2007 1:50:03 PM MST
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: I-D ACTION:draft-ietf-pwe3-pw-atm-mib-02.txt
>> Reply-To: [e-mail]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Pseudowire Emulation Edge to Edge 
>> Working Group of the IETF.
>>
>>      Title           : Managed Objects for ATM over Packet Switched
> Network (PSN)
>>      Author(s)       : T. Nadeau, et al.
>>      Filename        : draft-ietf-pwe3-pw-atm-mib-02.txt
>>      Pages           : 37
>>      Date            : 2007-2-13
>>     
>> This memo defines an experimental portion of the Management
>>    Information Base (MIB) for use with network management protocols 
>> in
>>    the Internet community.  In particular, it describes managed 
>> objects
>>    for modeling ATM Pseudowire (PW) carrying ATM cells over Packet
>>    Switch Network (PSN) as defined in the PWE3 [ATMENCAP]and 
>> [ATMTRANS].
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-atm-mib-02.txt
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-atm-mib-02.txt> 
>>
>> To remove yourself from the I-D Announcement list, send a message to 
>> [e-mail] with the word unsubscribe in the body 
>> of
>
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
<https://www1.ietf.org/mailman/listinfo/I-D-> 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the 
>> username "anonymous" and a password of your e-mail address. After 
>> logging in, type "cd internet-drafts" and then "get 
>> draft-ietf-pwe3-pw-atm-mib-02.txt".
>>
>> A list of Internet-Drafts directories can be found in 
>> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>      [e-mail].
>> In the body type:
>>      "FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-02.txt".
>>     
>> NOTE:        The mail server at ietf.org can return the document in
>>      MIME-encoded form by using the "mpack" utility.  To use this
>>      feature, insert the command "ENCODING mime" before the "FILE"
>>      command.  To decode the response(s), you will need "munpack" or
>>      a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>>      exhibit different behavior, especially when dealing with
>>      "multipart" MIME messages (i.e. documents which have been split
>>      up into multiple messages), so check your local documentation on
>>      how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader 
>> implementation to automatically retrieve the ASCII version of the 
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[e-mail]>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
<https://www1.ietf.org/mailman/listinfo/i-d-announce> 
>
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/pwe3/attachments/20070322/38a90b52/attachment
.html

------------------------------

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


End of pwe3 Digest, Vol 35, Issue 35
************************************


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