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

"Adrian Farrel" <> Fri, 10 May 2019 11:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9BA2120072; Fri, 10 May 2019 04:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hKTOcUVqgb6s; Fri, 10 May 2019 04:19:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8DDB12004E; Fri, 10 May 2019 04:19:18 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x4ABJGgQ010551; Fri, 10 May 2019 12:19:16 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id F09A022032; Fri, 10 May 2019 12:19:15 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id DB54A2203C; Fri, 10 May 2019 12:19:15 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x4ABJEcX031935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 May 2019 12:19:15 +0100
From: Adrian Farrel <>
To: 'Alvaro Retana' <>, 'The IESG' <>
Date: Fri, 10 May 2019 12:19:14 +0100
Organization: Old Dog Consulting
Message-ID: <00d801d50722$33c0e620$9b42b260$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdUHIYOcwzRJUqfgTsGz72IDr9VOxQ==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--20.246-10.0-31-10
X-imss-scan-details: No--20.246-10.0-31-10
X-TMASE-Result: 10--20.246300-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbLmR+C0l9vjVB5sxzt03wPgn+p552csI1X/2 0wqGUabSgvRaVUNx1oA5ze2drk/BuQ7Qbfq/wswqbMGKOuLn5FXvz6I3MheY8528BBVhm7jvwMG hP0Wjg/8XJVmJDt/51VQ4YPhxc47bf3WQIzVxGxZv/kcFnp29GDTbofuc5kuv3XgCp7wTMXxmrb vLF6LMLgbq/9JWy+kMJ4fuDlGgC6Ie5COU7dNCwlVN8laWo90M0Wobj8GkNVogbNDlPT+rW4wM3 oary3RStoK9gtwqtyq2a6lsK6mSwh1YpEPWJiyz/qwN14f3ZREF15s6prCIu5UQzHWBKOFAekWk qRyavwCC03PvXKVJmLoysPmOn/OfMYXCjAv0ws95TJVlfiK+u7Q0n3DEfu2TYOy4ZpFChjY9L7B Zz2Oj6BP8Ntjl+GIDKo6actS++6BlusJAgpCX441nuRzhSr7jAZn/4A9db2TbsLAxH00NyblxZG w/95HsYMkztX/J8vMMoVYXIfvgRNwMPYvQ+zxshv1+2J3yQFx+K68qL2G5psj0Eew4TN42SHgUV MoIv2EYJngu8BrbEJnmteZltT2lQ+RBSWLv95cqFAe/dEJJ6oLsLasl5ROhT83kZC2yygJSgkle /Q26sIPJ8Pia2rFaCWt1ymZP1D1wMSRURYxbpaKBmXefhKfGVcoOGM9lO6SsP4xgB5HN3zbfcoF SAemiXh+0IujVM3aPGVqDo0vLiOJUrMVOGm9V7DzBuedLDxtimi8LvNfmrxPuWwH3mlrqsYKQLF UbB7t5HVJlnaEFdvAZSzjX62dreg+NDxG2TtqeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1bxAi7jPoeEQftwZ3X11IV0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 May 2019 11:19:22 -0000

Hi Alvaro,

Having not seen any response to this email, I have now posted revision -05.


-----Original Message-----
From: mpls <> On Behalf Of Adrian Farrel
Sent: 03 May 2019 19:08
To: 'Alvaro Retana' <>; 'The IESG' <>
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS and COMMENT)

Hi again Alvaro,

Belatedly addressing your Discuss (for which renewed thanks).

> I am balloting DISCUSS because the specification is incomplete and not
> clear enough.  I have concerns about both the construction of forwarding
> entries, including the setting of the tunnel endpoints.
> (1) Forwarding Entries
> The procedures in §3.1 seem to want to be specified by example, but I
> think that this approach doesn't serve the document well as it goes into
> specifics for the protocols used in the example only (even using Normative
> language), and doesn't provide a general specification.  As §3 says, "the
> examples in Section 3.1 and Section 3.2 assume that OSPF or ISIS is
> enabled: in fact, other mechanisms of discovery and advertisement could
> be used including other routing protocols (such as BGP) or a central
> controller."  I would prefer if the text would talk about the general process
> first.  If the authors think that the examples serve an important function
> then it's ok to leave them.
> Others have raised the point about the link state extensions needing to
> be Normative references.  The way the text is written, Normative
> language is used in some cases to specifically talk about the use of those
> I would agree.  Using the extensions just in examples (and
> not mixing them with specification text) would solve that issue.
> What would I like to see?  For example, the third step talks about "If A
> and E are in different IGP areas/levels, then..."  How does the rest of the
> text help with understanding how BGP, for example, would be used?  In
> this case I believe that the step can be summarized into the need to
> advertise the SID and encapsulation with enough information so that the
> receiver "knows the characteristics of the router that originated the
> advertisement", even if not in the same routing/flooding domain (maybe:
> "information MUST be advertised across flooding domain boundaries..."
> -- I'm sure the authors can come up with better text).  Making that (or
> some text to the effect) the normative statement would be better than
> using normative language in the example (e.g. "MUST set the "router-ID"
> field to a valid value") and hoping/expecting for the reader to be able to
> translate that into whatever makes sense for BGP, or OSPFv3 or the
> central controller...  After the general specification, you can then use an
> example ("for example, if using OSPF, then the router-ID field is set to a
> valid value...").

[See also my response to Mirja]

I think this wibbliness may be due to a disagreement about whether it was even necessary to specify how the FIB was constructed since the process is just SR as usual. But (of course) we have the text and we must get it right.

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).

> (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.

> In the general case the statement is wrong: Yes, the tunnel destination should
> be the next SR-MPLS node, but that isn't always "the egress of the active node
> segment".  For example, in Figure 2 the SID could direct the traffic to the
> Egress Router (e.g. using it's Node SID) while having individual tunnels from
> the Ingress Router to the first SR, then to the next SR, etc., as explained in
> §3.2.1/3.2.2.

This is a little more complicated than it appears.

When the tunnel ends, the revealed packet will be an MPLS-SR packet, so it is clearly important that the tunnel can only end at an SR-MPLS capable node.

Now, the tunnel ingress must know the identity of the egress. That is, to tunnel you have to tunnel to somewhere.
There are two ways the tunnel ingress can do this:
- by extracting that information from the SID stack
- by learning from a routing protocol

The latter could be done by building an overlay topology map from the IGP information that identifies the SR-capable nodes. But this would also need some smarts because otherwise you would end up with a full mesh of tunnels. A better way of achieving it for the case in figure 1 would be using a VPN-like solution such as that described in draft-ietf-bess-datacenter-gateway.

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.

This means that there can be a variety of nodes on the packet's path as explained in Section 3.2. There are six types of node and one of them is:
| o Transit nodes that are SR-MPLS capable but that are not identified
|      by a SID in the SID stack.

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.

> I realize that the sentence after the statement above is "This is shown in
> Figure 1."  Figure 1 is a degenerate case of the (almost) general case from
> Figure 2.  Even in the single tunnel (Figure 1) case, "the egress of the active
> node segment" doesn't have to be R2, it could be another node inside the
> SR-MPLS network (as R2, being SR-MPLS aware, should be able to forward the
> frames).

No, I don't think it can.
While I understand that you *could* tunnel to R2 for a segment that ends beyond R2, I don't see how you would know to make/use that tunnel unless there was some programming at R1 to tell it that. (See the discussion above).
And, in summary, this is not the solution we have documented.

> 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.

As above, it will now read:

      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).

> 2. It is a general statement.  The placement is somewhat unfortunate because
> it seems that it may apply only to the Figure 1 case...but it applies in
> general...and there is no similar statement then describing other cases. 
> Instead of adding something similar for Figure 2, perhaps move the sentence
> to a place that covers all the use cases.

You're right, it applies to all tunnelling cases and the text can be dragged up above the bullet list.

> A third issue with the statement comes up when considering §3.1/§3.2:
> there is no specification there that explains how to figure out which
> should be the tunnel destination address.  The example in §3.1 only
> talks about receiving information from E, including the "the encapsulation
> endpoint and the tunnel type of any tunnel used to reach E"...but says
> nothing about other potential SR-MPLS capable nodes between A and E,
> or how A would use a tunnel to one of those transit nodes on the way to
> E...which is what is illustrated in §3.2.1/3.2.2.

It isn't the intention of this document to provide a full soup/nuts solution kit. It is much more an observation that 7510 can be used to achieve the function required.

Earlier revisions had more information on the possible control plane mechanisms that could be combined with the data plane encapsulations. 

For now, we content ourselves with pointers to a number of control plane drafts. We have added draft-ietf-bess-datacenter-gateway to that list.

> (3) A very, very late IPR declaration came in after the IETF LC started.
>  I didn't find a thread where the WG was made aware of it.

I hope my previous email (mid-April) on this addressed your concerns.


I hope my previous email (mid-April) on this addressed your concerns.

I'll be posting a new version soon.


mpls mailing list