Subject: Re: [Pals] WGC comments on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt

From: Mach Chen <[email-masked]>
Date: Sat, 31 Oct 2015 07:57:26 +0000

Hi Stewart,

Thanks for the detailed review!

Please see some replies inline, easy parts sniped.

Best regards,
Mach

> 
> 
>    If the receiving PE (PE2) is also an active PE, and may have
>    initiated the PSN binding requests to the other PE (PE1), if the
>    received PSN tunnel/LSP is the same as it has been sent in the Label
>    Mapping message by PE2, then the signaling has converged on a
>    mutually agreed Tunnel/LSP.  The binding operation is completed.
> 
>    Otherwise, the receiving PE (PE2) MUST compare its own Node ID
>    against the received Source Node ID.  If it is numerically lower, the
> 
> SB> You need to describe (hopefully by reference) the conversion of the
> SB> address to an unsigned integer, otherwise the text above is ambiguous.
> SB> I am sure that I have some text that I wrote with Dan Frost on this
> SB> but I cannot remember which RFC it was in.

I found the following in rfc6073:
  "The determination of which T-PE assumes the active role SHOULD be
   done as follows:

   The SAII and TAII are compared as unsigned integers; if the SAII is
   larger, then the T-PE assumes the active role."

Analog to above, I change the test as follows, how do you think?
"Otherwise, the receiving PE (PE2) MUST compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is larger, ..."

> 
>  On receive, since PE2 is also an active PE, and may have initiated
>    the PSN binding requests to the other PE (PE1), if the received PSN
>    tunnel/LSP has the same route as the one that has been sent in the
>    Label Mapping message to PE1, then the signaling has converged.  The
>    binding operation is completed.
> 
>    Otherwise, it needs to compare its own Node ID against the received
> SB> who is "it"?

It is PE2 , and will use "PE2" instead.

> 
>    Source Node ID.  If it is numerically lower,
> 
> 
>    a Label Mapping message with a PSN Binding TLV that contains the
>    Source and Destination IDs/Numbers in the appropriate order.
> SB> What does "appropriate order" mean?

How about this:

"a Label Mapping message with a PSN Binding TLV that contains the Source and Destination IDs/Numbers in the appropriate order (where the source is PE2 and PE1 becomes the destination)."
 
> 
>    However, if the new Label Binding message does not contain the PSN
>    Tunnel Binding TLV, it declares the removal of any co-routed/strict
>    constraints.  The PEs may not map the PW to the underlying PSN on
>    purpose, the current independent PW to PSN binding will be used.
> 
> SB> I do not understand the text from "However" to "used"

The tunnel binding update includes two options:

1.	change from tunnel A to tunnel B, or 
2.	remove the previously explicit tunnel (e.g., tunnel A) binding and revert to the status when such explicit binding does not used,  it lets the PEs to determine which tunnel will be used, just as the implementation without this document;  

The above paragraph is talking about option 2.

I read it again and found that “The PEs may not map the PW to the underlying PSN on purpose” is redundant and confusing. So I remove it, how about the following text?
"However, if the new Label Mapping message does not contain the PSN Tunnel Binding TLV, it declares the removal of any co-routed/strict constraints. The current independent PW to PSN binding will be used."

>    Otherwise, S-PE1 relays the Label Mapping message to the next S-PE
>    (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the
>    information of the new PSN tunnel/LSPs selected by S-PE1.  S-PE2 and
>    subsequent S-PEs will repeat the same operation until the Label
>    Mapping message reaches to the remote T-PE (that is, T-PE2).
> 
>    If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label
> 
> SB> what does "agrees with" mean?

How about "accepts"?