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

[Lizhong Jin <[e-mail]>]

Stewart, you are the best guy to join the review.

Regards
Lizhong


On Thu, Aug 20, 2015 at 8:25 PM, Stewart Bryant <[e-mail]> wrote:

> On 12/08/2015 16:45, [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
>
>
>
>