Subject: [Teas] Adam Roach's No Objection on draft-ietf-teas-assoc-corouted-bidir-frr-06: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 24 Oct 2018 21:22:30 -0700

Adam Roach has entered the following ballot position for
draft-ietf-teas-assoc-corouted-bidir-frr-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-assoc-corouted-bidir-frr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work everyone did on this document.

---------------------------------------------------------------------------

Please expand "LSP" in the abstract.

---------------------------------------------------------------------------

§3.3:

>  In this example, the mid-point node D may mistakenly associate LSP1
>  with the reverse LSP4 instead of the reverse LSP3 due to the matching
>  (Extended) ASSOCIATION Objects.

This doesn't seem right to me. LSP1 and LSP3 appear to be forward direction,
while LSP2 and LSP4 appear to be reverse direction. It's also not clear how LSP1
would be associated with LSP3 in this scenario, which is what this sentence
seems to be saying might happen.

Did this mean to say "...instead of the reverse LSP2..."?

---------------------------------------------------------------------------

§4.2:

>  In order to associate the LSPs unambiguously at a mid-point node (see
>  Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object
>  and add unique Extended Association ID for each associated forward
>  and reverse LSP pair forming the bidirectional LSP.  An endpoint node
>  MAY set the Extended Association ID to the value shown in Appendix A.

This phrasing is very confusing, as it implies that Appendix A is going to
contain a value that can be used as an ID (which would be at odds with
"unique"). Appendix A contains a format, not a value. I think what you mean is:

"...MAY set the Extended Association ID to a value formatted according to the
structure shown in Appendix A."

---------------------------------------------------------------------------

Appendix A:

>  Extended Association ID in the Extended ASSOCIATION Object [RFC6780]
>  can be set to the value shown in the following example to uniquely

Same comment as above regarding the distinction between "value" and "format".

---------------------------------------------------------------------------

Appendix A:

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    IPv4 LSP Source Address                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Reserved            |            LSP-ID             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What are implementors expected to set the "Reserved" bytes to?

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 26 Oct 2018 17:35:05 +0000

Thank you Adam for the review. Please see replies inline with <RG>…

On 2018-10-25, 12:22 AM, "Adam Roach" <[email-masked]> wrote:

    

    
    
<RG> Added.

    

    
<RG> Good catch, corrected.

    

<RG> Updated.

    

<RG> Updated.

    

<RG> Added: “The Reserved flags MUST be set to 0 on transmission and ignored when received.”
    
Thanks,
Rakesh

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Oct 2018 14:28:53 -0500

> <RG> Added: “The Reserved flags MUST be set to 0 on transmission and ignored when received.”

Are you sure that's right? If so, it's not clear how the recipient knows 
whether the Extended Association ID is in this format (as its use is a 
"may"), and whether it's safe to ignore them.  I would expect this to 
simply say that the Reserved bits are set to 0 on transmission without 
saying anything about reception. This isn't as much for the sake of the 
protocol (since the value doesn't really matter) as it is to help 
implementors out.

/a

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 26 Oct 2018 19:37:47 +0000

Hi Adam,

It’s a good point and agree. Updated the draft accordingly.

Thanks,
Rakesh

On 2018-10-26, 3:28 PM, "Adam Roach" <[email-masked]> wrote:

    
    /a

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Oct 2018 14:40:39 -0500

Thanks!

/a