[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some comments on draft-ietf-pwe3-segmented-pw-11

Sherry Xue wrote:

Hi,
I have reviewed the draft-ietf-pwe3-segmented-pw-11, and have some comments,
please find below.

1)	Section 4, some confused about figure 2, there are two "emulated
service" identifiers, between the egress of CE1 and ingress of CE2, also
between the ingress of PE1 and the egress of PE4.Does some amendment should
be done to avoid the reduplicate emulated service?
yes, it a mistake in the picture it now says: "Multi-Segment Pseudowire" at the top. 


2)	Section 4, in the penultimate paragraph, "this document describes
procedures for building multi-segment pseudo wires using manual
configuration of the switching point PE2", the Switching point" PE2" should
be "S-PE "which will be coincident with figure 3. And the identifier of the
Switch point in the sentence should be consistent with figure 3. 
it needs to be "PE1" I fixed it.


3)	Section 4, in the last paragraph, " no control messages are
exchanged yet as the S-PE PE dose not have.", there are a redundant "PE",
please delete it.


done.

4)	Section 4, in the last paragraph, sentence as "first the S-PE is
configured to switch a SS-PW from a specific peer to another SS-PW destined
for a different peer".
 I have some confusion about SS-PW definition used in the MS-PW as PW
segment role. SS-PW is defined as "a PW setup directly between two T-PE
devices. Each PW in one direction of a SS-PW traverses one PSN tunnel that
connects the two T-PEs." in the terminology section of [segmented-pw]. But

yes, it seems that the definition in  rfc5254 is incorrect.


SS-PW is defined "a PW setup directly between two PE devices. Each direction
of an SS-PW traverses one PSN tunnel that connects the two PEs" in RFC5254.
They are different, because SS-PW is terminated on different PE roles, T-PE
in former case, T-PE or S-PE in latter case. IMO, SS-PW should be setup between TWO T-PE devices, there are some 
differences between SS-PW and PW segment. If it is right, the SS-PW could
not be used the same as PW segment. So the sentence should be restructured
as "first the S-PE is configured to switch a PW segment from a specific peer
to another PW segment destined for a different peer...".  And concerted
action should be taken in the draft.


yes , this is correct , I will change it.
I also corrected this later in the status section.

5)	Section 7, in the first paragraph, the nomenclature should be
identical with figure 3, such as PE2, PE3 should be amended as S-PE and
T-PE, etc.


yes this was already fixed as pointed out by Stewart.
( I have not yet sent out the revised version.)


6)	Section 7.4, in the second sentence, Should the"PW switching point
TLV" in line 3 be "S-PE TLV"? In the fourth and fifth paragraphs, should the
"PW switching point TLV" in line 1 be "S-PE TLV"?


no, it's a personal editing choice, either way it's fine.


7)	Section 7.4.1, The title of section 7.4.1 should be accordant with
the title of section 7.4, so "S-PE sub-TLV" may be better?
I changed sec 7 , as strictly speaking i cannot use the abbreviation in the title. 
the RFC editor would have corrected that.


8)	Section 8, the title, "MPLS-PW to PW-L2TPv3 control plane switching"
may be amended as "MPLS-PW to L2TPv3-PW control plane switching"


yes, fixed.


9)	Section 8.4.1, I have some confused about the session establishment.
In the two example exchanges of message, I understand that the MS-PW is
setup in one direction totally, and then the other direction. Dose I make a
mistake? Now I have a question, take L2TPv2 PW- MPLS PW for example, whether
the L2tpv3 ICRP must be send after the LDP label mapping receiving from the
PE3? Should the PW switching node, map to LDP Label mapping forward and send
L2TPv3 ICRP backwards simultaneity?
Both cases work fine. It really depends who starts the process first : the L2TPv3 side or the MPLS side. 


And I have a question, which is why VCCV CC type 2 is not supported for
MS-PW? I think the reason is that the P device, which is neither S-PE nor
T-PE, is not responsible to inspect the VCCV message? That is right?
No. The problem is in processing the router attention label ( label 1). Also the real reason is that this mode is redundant , and was only supported to accommodate hardware limitations at the time when the VCCV document was written. This is no mode is longer necessary. 

Thanks for all your good comments !
I really appreciate a fresh set of eyes reading this document.

Luca
Regards 
Sherry