Re: [mpls] +AFs-mpls+AF0- Shepherd review of draft-ietf-mpls-spring-inter-domain-oam-10

[Adrian Farrel <[e-mail]>]

Hi Shraddha,

Thank you for your kind consideration of all my review points. You have done a really good job of covering them and just a few small issues remain.

I have snipped out everything that we are agreed on, and used the tag "[AF]" to mark my new comments.

Many thanks,
Adrian

1. para 8

   This mechanism uses
   MPLS path and no changes are required in the forwarding path.

I cannot parse this. Maybe s/MPLS path/MPLS LSPs/ ?
<SH> I mean to say the packet is being forwarded via MPLS so IP connectivity is not needed.
MPLS LSPs term will be too specific to LDP/RSVP I believe. SR RFCs don't use the term MPLS LSPs.

[AF] OK. I see your objection to "LSP" (even though I have disagreed with it for a long time :-)
My main problem is that the existing sentence does not parse.
Either:
   This mechanism uses
   MPLS paths and no changes are required in the forwarding path.
Or:
   This mechanism uses
   an MPLS path and no changes are required in the forwarding path.

---

4.2

Not all confusing to have TBD1, TBD3, and TBD4 (but no TBD2)  :-)

Aha! This is because you have a "TBA2" instead. Maybe change TBA to TBD.
Except, you also have a TBA1.

<SH> Assigned TBD1,TBD2, TBD3. Left TBA1, TBA2 as is. Hope that works for you.

[AF] This will work. At least, I am sure IANA can work it out, but please pay attention when you get the mail from IANA as they process the document.

---

6.1

   In the inter-AS scenario,the procedures described in this document
   should be used to specify the return path.

Is this "should" or "SHOULD"?
You are allowing variation (by using should not must) so you need to say why an implementation/deployment would choose to do something different.

<SH> The inter-AS deployment may not need procedures from this doc if ip connectivity to the initiator is available. That’s why the first statement
is not normative.

[AF] OK, I see your point. Maybe this can be clearer, such as...

   In the inter-AS scenario, the procedures described in this document
   are used to specify the return path if IP connectivity to the initiator is available,
   and may be used in any case.

---

[AF] Lumping the following two points together...

6.3

   In certain scenarios,  the
   head-end may choose to send Type C/Type D segments consisting of IPV4
   address or IPv6 address.

"may" or "MAY"?
Which scenarios and why make that choice?

<SH> changed to MAY
These are just implementation choices and I think it's not necessary to talk about
Why an implementation would choose to do it that way.

   Optionally SID may also be associated with
   the Type C/Type D segment.

"Optionally" or "It is OPTIONAL"?
How is his choice determined?

<SH> Again it's implementation choice.

[AF] The point here is that you are writing a spec for how an implementation behaves, and you say, "Hey, you could do this," but you don't give any hints as to why or how or what effect it will have.

In both cases, the implementer will worry about the effect of the choice and the benefits that might result.
You could at least say "...in order to <foo>" in both cases.

BTW s/IPV4/IPv4/ and s/Optionally SID/Optionally a SID/

---

6.3

   The reply path return code must be set as described in section 7.4 of
   [RFC7110].  The Reply Path TLV must be included in an echo reply
   indicating the specified return path that the echo reply message is
   required to follow as described in section 5.3 of [RFC7110].

"must" or "MUST"?  (twice)

<SH> These are from RFC 7110 and I was asked to remove MUST in previous review.

[AF] Oh, you are supplying commentary, not defining new behaviour. My bad. I think this is ...

The reply path code is set as described in section 7.4 of [RFC7110]. According
to section 5.3 of [RFC7110], the Reply Path TLV is included in an echo reply
to indicate the return path that the echo reply message is required to follow.

I don't think I am being *too* pedantic. The difference is between you defining normative behaviour (and "must" appears normative), and just reminding people to read 7110.

---


6.4

Is it possible that the TTL pre-increment is 255?

<SH> may be. If that happens, existing standards already specify what should be done.
This document is not going to change that.

[AF] Erm. Well, you have "in addition ... with the TTL incremented by 1" so it looks like you are defining new procedures.
I'd be happy with you to add "... with the case of the TTL already being 255 handled as described in [RFCxxxx]"

---

7.

   Example topologies given in Figure 1 and Figure 2 will be used

I think that your examples here all use ASBRs, so you are actually limiting yourself to Figure 1 except for the final paragraph of 7.2.2?

<SH> yes. That is correct. Anything to be clarified about this?

[AF] It's not a big deal (just trivial editorial), but I might change the opening of Section 7 to...
   The example topology given in Figure 1 will be used
...and leave the last para of 7.2.2 as it is with its specific reference to Figure 2

---

7.1

s/mpls/MPLS/

You have some non-ASCII characters

<SH> I fixed some but not sure I did the right way. Does IDnits catch this?

[AF] Yes. Idnits is now clean

---

8.1

Is "to traceroute" really a verb leading to the participle "tracerouted"?

<SH> This comment is too "technical" for me. Can you suggest correct sentence pls?

[AF] I think...
OLD
   To dynamically build the return Path for the traceroute procedures,
   the domain border nodes along the path being tracerouted should
   support the procedures described in this section.
NEW
   To dynamically build the return Path for the traceroute procedures,
   the domain border nodes along the path being traced should
   support the procedures described in this section.

---

8.1

   In cases when SRGB is not uniform across the network,
   it is RECOMMENDED to add a Type C or a Type D segment.

Fair enough, but why might an implementation choose to do otherwise and what are the benefits/implications?

<SH> some implementation may come up  with other smart ways of doing it.
This document will not restrict those implementation choices.

[AF] OK, you want to allow other behaviours, so perhaps...

   In cases when SRGB is not uniform across the network,
   it is RECOMMENDED to add a Type C or a Type D segment,
   but implementations MAY safely use other approaches if
   they see benefits in doing so.