[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-sr-epe-oam-18: (with DISCUSS and COMMENT)

[Shraddha Hegde <[e-mail]>]

Hi John,

Thanks for the review and comments.
Pls see inline for replies.
Ver -19 will address your comments.

Rgds
Shraddha


Juniper Business Use Only
-----Original Message-----
From: John Scudder via Datatracker <[e-mail]>
Sent: Tuesday, July 9, 2024 3:39 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: John Scudder's Discuss on draft-ietf-mpls-sr-epe-oam-18: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


John Scudder has entered the following ballot position for
draft-ietf-mpls-sr-epe-oam-18: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!E_d0RZXlkDUphzbFhMdcu5AHInGBBxXi9zI4-QLsEO8Lc1KTbluFoP-5ofr4JoUPIgi9qjFvtZQHFDzM$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-epe-oam/__;!!NEt6yMaO-gk!E_d0RZXlkDUphzbFhMdcu5AHInGBBxXi9zI4-QLsEO8Lc1KTbluFoP-5ofr4JoUPIgi9qjFvtVO8Otvw$



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

# John Scudder, RTG AD, comments for draft-ietf-mpls-sr-epe-oam-18 CC @jgscudder

Thanks for the document. I have a few DISCUSS-level concerns (but I think they will be easy to fix), and a couple of other comments.

## DISCUSS

### Sections 4.1, 4.2, and 4.3, Confederations

These three sections have similar or identical text defining the local and remote AS numbers, as follows,

   Local AS Number :

   4 octet unsigned integer representing the Member-AS Number inside the
   Confederation [RFC5065].  The AS number corresponds to the AS to
   which PeerNode SID advertising node belongs to.

   Remote AS Number :

   4 octet unsigned integer representing the Member-AS Number inside the
   Confederation [RFC5065].  The AS number corresponds to the AS of the
   remote node for which the PeerNode SID is advertised.

Although I am naturally a huge fan of confederations, I don't understand why you are referencing them here, in this way. Surely this document is not restricted to use only with confederations (if it were it would need a lot more explanation!).

My guess is you're trying to solve the problem where the local and remote nodes are both within the same Confederation, but different Member-ASes. If so, perhaps something like the following,

NEW:

   Local AS Number :

   The 4-octet AS number of the AS to which the PeerNode SID advertising
   node belongs. If Confederations [RFC5065] are in use, and if the
   remote node is a member of a different Member-AS within the local
   Confederation, this is the Member-AS Number inside the Confederation
   and not the Confederation Identifier.

   Remote AS Number :

   The 4-octet AS number of the AS of the remote node for which the
   PeerNode SID is advertised. If Confederations [RFC5065] are in use,
   and if the remote node is a member of a different Member-AS within
   the local Confederation, this is the Member-AS Number inside the
   Confederation and not the Confederation Identifier.

I don't know how picky you want to get, but the case not covered in my proposed text is if confederations are in use, but the local node and remote node are in different Confederations. In that case, their respective Confederation Identifiers would be used, but it simplifies to the "AS number" case since a Confederation Identifier is just a (globally visible) AS number. As far as I'm concerned that's obvious enough not to need saying, but YMMV.
<SH> Thanks for the text. I'll use this.

### Sections 4.1, 4.2, and 4.3, "advertising node"

These three sections all refer to the "advertising node". I presume this means, "the node that advertised the information into BGP-LS". But is that really what you mean? Keep in mind that by design, sometimes no other than the local one can advertise information into BGP-LS as a proxy for the other node.

I was thinking of proposing different terminology to remedy this problem, but I see RFC 9086 has the same defect (of assuming that the node that owns the SID will be the one that advertises it into BGP-LS), so we may as well stick with it. However, I think it would be helpful to be clear about exactly what "advertising note" means, every time you say it. You've already got a pattern for this in your document, e.g. in Section 4.2 you have "PeerAdj SID advertising node" which is good enough -- I suggest just replicating that pattern and never abbreviating down to "advertising node".
<SH> Ok fixed.

### Sections 4.1, 4.2, and 4.3, "receiving node"

These three sections all refer to the "receiving node". The most obvious and usual reading of "receiving node" is, the node that receives the BGP-LS message carrying the sub-TLV in question. I think that can't be what you mean. I think what you mean is "remote node".
<SH> yes. Fixed this problem as part of Zaheduzzaman Sarker's comments

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


## COMMENT

### Section 4.3, order of description text

Please sort your field descriptions in the same order the fields appear in Figure 5. The out-of-order description threw me off badly on my first read-through.
<SH> ok

### Sections 5 and 5.1, "augments"

Section 5 says,

   The below section augments the section 7.4 point 4a of
   [RFC8287].

And then Section 5.1 provides the augmentation.

Looking at RFC 8287 I feel sad because the referenced section there already "modifies the procedure defined in Section 4.4.1 of [RFC8029]." But at least
8287 is a straight replacement for the 8029 text -- or I think it is, the language of 8287 is not clear on this point. :-(

Since RFC 8287 §7.4 (4a) is essentially a big disjunction, it makes sense that you can take your text and paste it onto the end of 4a. And I agree that for the same reason, it doesn't matter whether it's appended to the end, placed at the beginning, or even interleaved. However for clarity, I think it would save some future reader my confusion if you reworded the quoted text as,

   The below section is appended to the procedure given in Section 7.4
   point 4a of [RFC8287].
<SH> OK

It would also be nice if you followed the pseudo-code convention established in RFC 8287 since you're augmenting that body of pseudo-code. Yours is close, but for example, you don't use braces "{ }" where 8287 does, you don't use the same bullet conventions, etc. I imagine if there are things it's too much effort for you to fix in your source, you could ask the RFC Editor for help with those.
<SH> I  fixed the braces and bullet conventions, might need some more editing from RFC Editor.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues.

[ICMF]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!E_d0RZXlkDUphzbFhMdcu5AHInGBBxXi9zI4-QLsEO8Lc1KTbluFoP-5ofr4JoUPIgi9qjFvtSI9PP5O$
[ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!NEt6yMaO-gk!E_d0RZXlkDUphzbFhMdcu5AHInGBBxXi9zI4-QLsEO8Lc1KTbluFoP-5ofr4JoUPIgi9qjFvtXE2rB6o$