Subject: RE: Multi-Hop Pseudo-Wires Signalling Using LDP

From: [email-masked]
Date: Fri, 18 Feb 2005 12:02:09 +0800

I'm so sorry for the delay to reply. I just have a vacation for sixteen
days.

thank you very much.

Regard,
Du Ke

> -----Original Message-----
>     2005-02-01 23:27
>     From： David McDysan <[email-masked]>
>     To： "'pwe3'" <[email-masked]>
>     Topic： RE: [PWE3] Multi-Hop Pseudo-Wires Signalling Using LDP
>
> Interesting draft. A few comments and questions below.
>
> Dave
>
> Agree that hierarchy is an important driver. Suggest reference of the
> requirements I-D that describes the use cases for hierarchy in more
detail.
> draft-martini-pwe3-MH-PW-requirements-00.txt

DK=>Yes. That requirements I-D is one of the references of ours. We are
making
great efforts to explain clearly which use cases this paper arms to, but it
seems to be not enough what we have done. Please folks give us more
comments,
and help to improve.

>
> Should additional parameters be encoded in a separate TLV instead of
> augmenting the Generalized ID (GID) FEC already defined in
> draft-ietf-pwe3-control-protocol-11.txt? This could ease interoperability
> considerations.

DK=>A separate TLV maybe a good idea, but I think that the vector
      < Source PE, <AGI, SAII>, Target PE, <AGI, TAII>>
is a whole to identify a PW (or MH-PW). Logically, it's better to let
parameters, Source PE Identification and Target PE Identification, be a
part
of GID.
On the other hand, GID FEC Element itself is a tlv-encoded parameter. an
other optional parameter being added into it will not be harmful. The FEC
Type of the GID FEC Element uses element type 129 all the same. If the
optional parameters of U-PE ID appear, it's 'Extended GID FEC Element'.
Otherwise, it's normal 'GID FEC Element'.
Maybe we SHOULD point out these parameters are optional explicitly in
section 5 (Extended GID FEC Element).

>
> The proposed next-Hop LSR ID TLV can be inferred from the LDP peer.
> Therefore, is this TLV necessary?

DK=>Yes. As an "Reflector" can have two modes to switch PW Label messages.
One is simple relay mode, the other is the nexthop-self mode. In the case
below:
       U-PE1 --- Reflector --- U-PE2
If Reflector works in the "nexthop self" mode, it will not add next-Hop
LSR ID TLV into mapping message, or add a next-Hop LSR ID TLV with nexthop
lsr id being U-PE2's, then U-PE1 can be indicated to use U-PE2 as data
plane
nexthop (the other end of PSN tunnel).
LDP peer isn't always the data plane nexthop.

>
> The proposed next-hop priority TLV could be learned from BGP (local pref)
or
> an IGP (metric) for the LDP peer. Therefore, is this TLV necessary?

DK=>PW layer is a layer network. It should have its own policy.

>
> Does the "Reflector" in section 4.1, simple trunk mode, need to withdraw
> labels if a session with an LDP client fails?

DK=>Yes. If all received label mapping for a MH_PW are withdrawn, the
reflector MUST send corresponding label withdraw to the target U-PE
or other reflectors, and MUST cancel all status about that MH-PW
after receiving all label release responses.

>
> A few comments on section 4.2, "nexthop self" mode.
>
> Suggest use of source/dest PE terminology defined at the end of section 1
to
> improve readability throughout. Section 4.2 section uses terms such as
> "far-end" and "dest," and references to a particular PE are sometimes
> unclear later in the document.

DK=>Yes. We'll fix it.

>
> The "reflector" described with reference to Figure 4-2 appears to be
similar
> to a PW Switching PE (S-PE) function in the terminology defined in
> draft-martini-pwe3-MH-PW-requirements-00.txt where the PW FEC is the same
> for all segments. Also, the S-PE determines the next hop toward the
target,
> as opposed to having to configure a "stitching" point.
>
> The "reflector" described with reference to Figure 4-3 appears to be
similar
> to PW Stitching of SH PW segments, which may have different PW FECs and
> different PSN tunnel types as described in
> draft-martini-pwe3-pw-switching-01.txt.

DK=>Are they Figure 4-2 and 4-3 in
"draft-yudong-pwe3-control-protocol-ext-00.txt"?

>
> A unique aspect of the described approach is that the proposed extenstion
to
> PW LDP is used to "flood" the label binding from the source PE (i.e., the
PE
> distributing the PW label) to all "reflector" nodes until the target PE
is
> reached, creating the need for loop detection as described in section 9.
> This has the consequence that PW labels and other resources (e.g.,
capacity
> if that is signaled) are reserved on all possible PW paths. This could be
> inefficient in some topologies or applications.
>
DK=>Yes. To solve it, The section 8 (Routing) is added in
"draft-yudong-pwe3-
control-protocol-ext-01.txt". Richard Spencer (British Telecom) and Peter
Busschbach contributed greatly to the notion of routing of PW label
messages.

***********************************************
信息安全声明：本邮件包含信息归ZTE所有，
ZTE对该邮件拥有所有权利。请接收者注意
保密，未经发件人书面许可，不得向任何第
三方组织和个人透露本邮件所含信息的全部
或部分。以上声明仅适用于工作邮件。
Information Security  Notice：
The information contained in this mail is
solely property of  ZTE Corporation. 
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.
***********************************************
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3