Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

On May 3, 2019 at 2:08:01 PM, Adrian Farrel ([e-mail]) wrote:

Adrian:

Hi!

Sorry for the long delay...

...

> (1) Forwarding Entries

...

Your suggestion is the right way forward. That is, text that is generic and
definitive (the main Section 3.1), and more detailed text that is the
examples currently present with the 2119 language removed (moved into
3.1.1).

I looked at -05, and the text there works for me.

Just one detail (non-blocking): the third step (§3.1) says "If A and E are
in different IGP domains…”. Strictly speaking, specially because we could
be dealing with BGP, that should be “different routing domains” — while
most of the time different autonomous systems, even under the same
administration, will use different IGP domains, that is not always the
case.  Generalizing to “routing domains” sounds better to me.


> (2) Tunnel Endpoints
>
> §2: "The tunnel selected MUST have its remote end point (destination)
address
> equal to the address of the next SR-MPLS capable node along the path
(i.e., the
> egress of the active node segment)." I find this statement misleading and
> confusing.

Confusing is not good.

...

But what we have chosen to do is focus on the case where the tunnel targets
the next node in the SID stack. If you think about it, even in the case for
figure 1, the remote site might be dual homed and it will be important to
select the correct entry point, a feature that is only made possible by
directing the tunnel (possibly based on routing information as suggested in
draft-ietf-bess-datacenter-gateway) to the correct entry point since
otherwise the IP-enabled connecting network will just use a shortest path
approach.

...

Thus you are right that the text needs to be fixed.

It really should be "The next SR-MPLS-capable node identified as being on
the SR path." That is, "The egress of the active node segment" in all cases.


The text changed from (in -03):

"The tunnel selected MUST have its remote end point (destination) address
equal to the address of the next SR-MPLS capable node along the path (i.e.,
the egress of the active node segment).”

…to:

"The tunnel selected MUST have its remote end point (destination) address
equal to the address of the next SR-MPLS capable node identified as being
on the SR path (i.e., the egress of the active node segment).”

IOW, the change was s/the next SR-MPLS capable node along the path/the next
SR-MPLS capable node identified as being on the SR path

I have no idea what the difference between those two phrases is.  To me,
they say the same thing. :-(

...

As I mentioned before:

> 1. It is wrong. I think that what makes it wrong is the clarification that

> "the next SR-MPLS capable node along the path" is "the egress of the
active
> node segment". Taken the text is parenthesis out would solve this issue.

My problem is not with the text you changed, but with the clarification:
"the egress of the active node segment”.  Specifically, I think that the
characterization as a *node segment* is wrong.  Following your example
above through draft-ietf-bess-datacenter-gateway…it proposes (§5) using a
prefix-SID to do the directing…which doesn’t always result in a node
segment (rfc8402).

Yes, I guess I’m arguing about terminology.  To me this is an important,
specially because this is a document on the Standards Track, so that the
control plane solutions can do their thing…

As I suggested before, taking out the clarifying phrase will satisfy my
point.  Also will s/the egress of the active node segment/the egress of the
active segment


I trust that you and the Responsible AD will do the right thing, so I’m
clearing my DISCUSS.

Thanks!

Alvaro.