Subject: [PWE3] 答复: pwe3 Digest, Vol 63, Issue 22

From: [email-masked]
Date: Tue, 18 Aug 2009 10:02:46 +0800

Hi,
This is my comments about the third topic,please see inline.

regrads,
chen

[email-masked] 
发件人:  [email-masked]
2009-07-28 03:00
请答复 给
[email-masked]

收件人
[email-masked]
抄送

主题
pwe3 Digest, Vol 63, Issue 22

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/pwe3

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send pwe3 mailing list submissions to
                 [email-masked]

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

You can reach the person managing the list at
                 [email-masked]

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

Today's Topics:

   1. PWE3 presentations (David Sinicrope)
   2. I-D Action:draft-ietf-pwe3-vccv-bfd-07.txt
      ([email-masked])
   3. P2MP PW REQ Stockholm discussion
      ([email-masked])
   4. ICCP draft and mLACP (Sadler, Jonathan B.)

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

Message: 1
Date: Sun, 26 Jul 2009 13:18:06 -0700
From: David Sinicrope <[email-masked]>
Subject: [PWE3] PWE3 presentations
To: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi All,
I'm still missing several presentations for Mondays session.  Please 
send them as soon as possible.
Thanks,
Dave

------------------
David Sinicrope

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

Message: 2
Date: Mon, 27 Jul 2009 06:00:01 -0700 (PDT)
From: [email-masked]
Subject: [PWE3] I-D Action:draft-ietf-pwe3-vccv-bfd-07.txt
To: [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

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

Message: 3
Date: Mon, 27 Jul 2009 17:20:33 +0200
From: <[email-masked]>
Subject: [PWE3] P2MP PW REQ Stockholm discussion
To: <[email-masked]>
Message-ID: <AFC377AFCC0FBD4DABE49F4B81EC4F1A518FF6@ftrdmel1>
Content-Type: text/plain; charset="us-ascii"

Hi all,

As explained during my presentation, the P2MP REQ draft has still a few
open issues.
Please let us know your thoughts about the following topics:

1\ P2MP PW MAY be bidirectional. 
Initially this requirement is optional , since that does not address
most of applications we get in mind (see VPMS draft). But please let us
know if there are some reasons to consider this feature as mandatory
I support. For example time distribution scenrios where a reverse path is 
necessary. There should be a reverse path for the slave device to 
paticipate in the whole synchronization procedure (e.g. three-way 
handshake).
2\ Leaf attachment acknoledgement (so from the leaf to the root). 
The Egress PE ack to the root is necessary for at least both reasons 
                 - RSVP-TE P2MP LSP as underlying Layer: the root PE can
update/extend the P2MP TE-LSP accordingly 
                 - RSVP-TE or MLDP LSP as underlying Layer: multiplexing 
rules of
P2MP PW/P2MP LSP (mapping 1:1 to N:1)
However this ack does not represent exactly the leaves of the PW tree
since the Egress PE may deliver the traffic to more than one attached AC
(see Reference Model).
We request the AC ack from the Egress PE to the Ingress PE for NMS
purpose but that can be also relevant for specific protection scheme per
AC. 
Once more let us know your opinion 
Thanks,
Fred
I wonder which scenrios the "NMS purpose" applies to. The NMS could 
monitor the P2MP PW status through SNMP from both the Ingress and Egress 
PEs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://www.ietf.org/mail-archive/web/pwe3/attachments/20090727/0b3c79af/attachment.htm

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

Message: 4
Date: Mon, 27 Jul 2009 11:58:59 -0500
From: "Sadler, Jonathan B." <[email-masked]>
Subject: [PWE3] ICCP draft and mLACP
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tony Jeffree
                 <[email-masked]>,           "[email-masked]" 
<[email-masked]>
Message-ID:
 
<[email-masked]>
 
Content-Type: text/plain; charset="iso-8859-1"

Hello Luca,

At PWE3 today, you asked the question if the technology specific details 
in the ICCP draft (found at 
http://tools.ietf.org/html/draft-ietf-pwe3-iccp-00) should be split out 
from the base document.  I indicated my support for a split and wanted to 
let you know my reasoning.

Within the last 2-3 years, IEEE has identified that 802.3ad doesn't have a 
requirement to be bound to Ethernet, nor does it need to be bound to a 
single-node to single-node deployment.  This has led to the agreement that 
work on LAG be moved from 802.3 and into 802.1.  As a result of the move 
in responsibility, 802.3 has removed clause 43 from the 802.3 
specification, and 802.1 has placed the text into its own document: 
802.1AX-2008.  Extensions to 802.1AX for Multi-Chassis LAG, etc. are 
expected to be developed for this document.

While the work on Multi-Chassis LAG (i.e. allowing LAG to operate in a 
multi-homed configuration as shown in the ICCP draft) is still on the 
"todo" list in 802.1 for 802.1AX, it requires essentially the same sort of 
information that has been included in section 7.2 of the ICCP draft. 
Defining the protocol to carry this information (e.g extensions to 
LDP/development of ICCP) can be stated as something IETF is a master of, 
but the required data for the application and NE behaviours are probably 
best co-developed with IEEE.  Not only would this get the correct experts 
involved in the development, it would allow for commonality with a 
non-MPLS based solution.

By placing the technology specific bits into a separate I-D, the base ICCP 
draft has any encumbrance removed and can progress quickly.  If IEEE is 
not interested in developing multi-chassis then I can understand IETF 
progressing the mLACP application work independantly.  However, it would 
be bad (in my mind) to have duplicate work done in IETF (developing an 
MPLS specific solution) and in IEEE (developing an general Ethernet spec).

I hope this helps.

Jonathan Sadler

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://www.ietf.org/mail-archive/web/pwe3/attachments/20090727/d53272c1/attachment.htm

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

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

End of pwe3 Digest, Vol 63, Issue 22
************************************

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.