Re: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

[Jiangyuanlong <[e-mail]>]

Hi Stewart,

A new revision has been uploaded which is based on the previous discussions:
https://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-pe-etree-08.txt

And I would like to have a conference call to further discuss with Lizhong on his concerns and those proposed resolutions.

Thanks,
Yuanlong



From: Stewart Bryant [mailto:[e-mail]]
Sent: Thursday, August 20, 2015 8:26 PM
To: [e-mail]; Jiangyuanlong; rtg-ads; david.i.allan; Fedyk, Donald (Don); Giles Heron (giheron); agmalis
Cc: rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: Re: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt

On 12/08/2015 16:45, [e-mail]<mailto:[e-mail]> wrote:



13.   Section5.2: “For both methods, VLAN mapping parameters from a remote PE can be provisioned or determined by a signaling protocol as described in Section 6 when a PW is being established”. For the global method, why we need signaling?
[JY] Just as the sentence says, the global VLAN method does not rely on signaling for its work.
But the SPs may prefer to use one method (e.g., global VLAN based) in scenario A and the other method (e.g., local VLAN based) in scenario B, and they would like to keep both methods work in a similar way, so the signaling protocol was designed to be applicable in both methods to give them a similar operation experience (if signaling is supported).
[Lizhong] I don't agree, what if deploying only global mode? You are talking about the operational experience, but I am talking about the technology. It is very confusing for the readers.
[JY2] Firstly, signaling for global method is not mandatory. Secondly, when control plane is needed, it is simple to implement if the same signaling can be used in both cases. BTW, even in the global mode, we may save some work in configuration if we have signaling capability (thus we only need to configure two VLAN values per router).

SB> I honestly do not understand the problem with the original text.

SB> Sure if you only use global you do not NEED signalling, but if you want to implement it that way it will work, and the text makes it clear that signalling is optional.



==========
19.   Section6.1: “If the PE is a leaf-only node itself, then a label release message with a status code "Leaf to Leaf PW released" is sent to the peer PE and exit the process;” When both PE release the mapping. Then when one PE1 change the setting to have both root&leaf, and send label mapping to PE2, will PE2 be triggered to send label mapping to PE1? According to RFC5036, I think the answer is no. You need additional mechanism here.
[JY] Why PE2 cannot be triggered to send label mapping to PE1? IMO, we don't need any additional mechanism here. If the configuration is changed for a failed PW establishing session, then a new round of PW negotiations can take place between PE1 and PE2. Furthermore, the PW negotiation process is standardized in RFC 4447 rather than RFC 5036, and you can find answers there.
[Lizhong] You should give out the technical reason. There is no configuration changing on PE2, and PE1 release the mapping from PE2, then the PE2 will not send mapping again since DU mode is used for PW signaling. BTW, the PW signaling RFC4447 is based on RFC5036, and also updated by RFC6723. One method is, like RFC6723, PE1 need LDP request message to reestablish the PW.

SB> The correct document to use as the basis for this discussion is 4447bis, since that is the description of PW signalling that has all the errors corrected.

SB> So is this protocol broken if the procedures in RFC4447bis are applied?


[JY2] this is similar to comment 20 since it deals with topology and TLV parameter updates.


Also can I suggest that the document is updated with the changes we know we are going to make so we know exactly what text we are dealing with and can deal with the unresolved issues withing that context.  When we have the text technically correct we will then need to do an English Language pass to pick up the concerns raised by our AD. However I am reluctant to do this, or ask someone else to do do it before the outstanding technical issues are all fixed.

If you think it is useful to set up a conference call to resolve this please let me know.

- Stewart