Subject: [mpls] Alia Atlas' Discuss on draft-ietf-mpls-residence-time-14: (with DISCUSS and COMMENT)

From: Alia Atlas <[email-masked]>
Date: Wed, 01 Mar 2017 15:05:52 -0800

Alia Atlas has entered the following ballot position for
draft-ietf-mpls-residence-time-14: Discuss

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-mpls-residence-time/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for a clear document.  I think that this should be a
straightforward Discuss to better clarify.

In Section 4.8.1, it says "The RTM Set sub-object contains an ordered
list, from egress node to
   ingress node, of the RTM capable nodes along the LSP's path." but the
sub-TLVs (as most clearly
indicated by "4.8.1.3.  Unnumbered Interface Sub-TLV" are actually meant
to be a list of interfaces.
It isn't clear whether these are supposed to be the egress interface, the
ingress interface, or just any
interface - or why sending just a Router ID wouldn't be sufficient.  
There is no indication as to whether
it is ok to include both the IPv4 and IPv6 address Sub-TLVs for the same
node or how to select which one
to use.

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

1) I am disappointed that the sub-TLV needed for an OSPFv3 Extended LSA
isn't defined.  While I understand that a normative reference isn't
desirable - instead of "left for future study", it would be better to say
that the sub-TLV should use the same format as in Sec 4.3 and that the
type allocation and full details are left to a future document.   This is
exactly how gaps are created for networks running only IPv6.   If
draft-ietf-ospf-ospfv3-lsa-extend-13 were not waiting for implementations
and had a clear time-frame for how and when to progress, this would also
be a Discuss.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Mar 2017 23:01:08 -0800

Hi Alia,
thank you for your thorough review and the comments. Please find my
responses in-line tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
GIM>> I think that the text, e.g. by stating "The Length is always 12" and
the Figure 10 are clear that only one interface can be listed in the
sub-TLV.
And the same is true for other sub-TLVs.

> interface

GIM>> In order for the process described in section 4.8 to work RTM node
MUST use the same ID in RTM_SET sub-TLV as in RRO subobject.

> - or why sending just a Router ID wouldn't be sufficient.
GIM>> Selection should follow election of ID for corresponding subobject in
RRO.

GIM>> I agree that your proposal narrows the gap for IPv6 extension for RTM
capability advertisement. Will apply the text you've suggested in the next
version. Hope OSPF WG agrees to this change.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 2 Mar 2017 09:48:46 -0500

Hi Greg,

> And the same is true for other sub-TLVs.

The draft says"Only a single RTM_SET  sub-TLV with the given Value field
MUST be present in the RTM_SET   TLV.  If more than one sub-TLV is found
the LSP setup MUST fail"

There is nothing there that clearly states that only one of the 3 sub-TLVs
should be place in the RTM_SET TLV for a particular node.  There is also
the inaccuracy between putting in interface addresses versus the claim that
it contains nodes.

For instance, text could be added/changed to indicate:

"The RTM_SET TLV is intended to include the subset of the RRO Object that
represents those egress interfaces on the LSP that are RTM-capable.  After
a node chooses an egress interface to use in the RRO sub-TLV, that same
egress interface, if RTM-capable,  SHOULD be placed into the RTM_SET TLV
using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface
sub-TLV.  The address family chosen SHOULD match that of the RESV message
and that used in the RRO; the unnumbered interface sub-TLV is used when the
egress interface has no assigned IP address.  A node MUST NOT place more
sub-TLVs in the RTM_SET TLV than the number of RTM-capable egress
interfaces the LSP traverses that are under that node's control."

> MUST use the same ID in RTM_SET sub-TLV as in RRO subobject.

Right - but I don't see the draft saying that clearly.  See my suggested
text above.

> GIM>> Selection should follow election of ID for corresponding subobject
> in RRO.
>

Agreed - see suggested text.

> GIM>> I agree that your proposal narrows the gap for IPv6 extension for
> RTM capability advertisement. Will apply the text you've suggested in the
> next version. Hope OSPF WG agrees to this change.
>

Thanks.

Regards,
Alia

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Mar 2017 08:37:33 -0800

Hi Alia,
thank you for the proposed text. Accepted. Please see the updated text
below.

Regards,
Greg

On Thu, Mar 2, 2017 at 6:48 AM, Alia Atlas <[email-masked]> wrote:

> OLD TEXT:

   Sub-TLVs are organized as a last-in-first-out stack.  The first -out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.  Only a single RTM_SET
   sub-TLV with the given Value field MUST be present in the RTM_SET
   TLV.  If more than one sub-TLV is found the LSP setup MUST fail with
   the generation of a PathErr message with the Error Code "Duplicate
   sub-TLV" Section 8.9
<https://tools.ietf.org/html/draft-ietf-mpls-residence-time-05#section-8.9>
and Error Value contains 16-bit value composed
   of (Type of TLV, Type of sub-TLV).

NEW TEXT:

   Sub-TLVs are organized as a last-in-first-out stack.  The first-out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.

   The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs
   that represents those egress interfaces on the LSP that are RTM-
   capable.  After a node chooses an egress interface to use in the RRO
   sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed
   into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or
   Unnumbered Interface sub-TLV.  The address family chosen SHOULD match
   that of the RESV message and that used in the RRO; the unnumbered
   interface sub-TLV is used when the egress interface has no assigned
   IP address.  A node MUST NOT place more sub-TLVs in the RTM_SET TLV
   than the number of RTM-capable egress interfaces the LSP traverses
   that are under that node's control.  Only a single RTM_SET sub-TLV
   with the given Value field MUST be present in the RTM_SET TLV.  If
   more than one sub-TLV is found the LSP setup MUST fail with the
   generation of a ResvErr message with the Error Code "Duplicate sub-
   TLV" Section 7.9 and Error Value contains 16-bit value composed of
   (Type of TLV, Type of sub-TLV).

> OLD TEXT:

   The capability to support RTM on a particular link (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend
<https://tools.ietf.org/html/draft-ietf-mpls-residence-time-14#ref-I-D.ietf-ospf-ospfv3-lsa-extend>].
Exact use of OSPFv3 LSA
   extensions is for further study.

NEW TEXT:

   The capability to support RTM on a particular link (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend].  The sub-TLV SHOULD use the same
   format as in Section 4.3.  The type allocation and full details of
   exact use of OSPFv3 LSA extensions is for further study.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 2 Mar 2017 11:40:52 -0500

LGTM - thanks!

I'll clear now - assuming you will post the updated draft.

Regards,
Alia

On Thu, Mar 2, 2017 at 11:37 AM, Greg Mirsky <[email-masked]> wrote:

>> There is nothing there that clearly states that only one of the 3
>> sub-TLVs should be place in the RTM_SET TLV for a particular node.  There
>> is also the inaccuracy between putting in interface addresses versus the
>> claim that it contains nodes.
>>
>    sub-TLV" Section 8.9 <https://tools.ietf.org/html/draft-ietf-mpls-residence-time-05#section-8.9> and Error Value contains 16-bit value composed
>    [I-D.ietf-ospf-ospfv3-lsa-extend <https://tools.ietf.org/html/draft-ietf-mpls-residence-time-14#ref-I-D.ietf-ospf-ospfv3-lsa-extend>].  Exact use of OSPFv3 LSA

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Mar 2017 08:43:19 -0800

Thank you!
Will work on other comments we've received and post the update then.

Regards,
Greg

On Thu, Mar 2, 2017 at 8:40 AM, Alia Atlas <[email-masked]> wrote:

>>> "The RTM_SET TLV is intended to include the subset of the RRO Object
>>> that represents those egress interfaces on the LSP that are RTM-capable.
>>> After a node chooses an egress interface to use in the RRO sub-TLV, that
>>> same egress interface, if RTM-capable,  SHOULD be placed into the RTM_SET
>>> TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered Interface
>>>> GIM>> In order for the process described in section 4.8 to work RTM
>>>> node MUST use the same ID in RTM_SET sub-TLV as in RRO subobject.
>>>>
>>>
>>>> GIM>> Selection should follow election of ID for corresponding
>>>> subobject in RRO.
>>>>
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Mar 2017 09:49:40 -0800

Hi Alia, et. al,
the new version of the draft has been uploaded. It includes the changes
we've discussed as well as addresses comments we've received from Mirja,
Spencer, Ben, and Benjamin.
Thank you for your help and patience.

Regards,
Greg