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

"Adrian Farrel" <> Fri, 03 May 2019 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02CD31200D5; Fri, 3 May 2019 11:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 811xgxKZHREI; Fri, 3 May 2019 11:08:04 -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 3F638120020; Fri, 3 May 2019 11:08:04 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x43I80x3019183; Fri, 3 May 2019 19:08:00 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 890472204A; Fri, 3 May 2019 19:08:00 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 737AB2204C; Fri, 3 May 2019 19:08:00 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x43I7wbX011756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 May 2019 19:07:59 +0100
From: Adrian Farrel <>
To: 'Alvaro Retana' <>, 'The IESG' <>
Cc:, 'Loa Andersson' <>,,
References: <>
In-Reply-To: <>
Date: Fri, 03 May 2019 19:07:59 +0100
Organization: Old Dog Consulting
Message-ID: <070801d501db$24c08500$6e418f00$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGXr/5JRm+SoBSwKycFVDyv9ALddqbMpw6Q
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--22.755-10.0-31-10
X-imss-scan-details: No--22.755-10.0-31-10
X-TMASE-Result: 10--22.755500-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbJmug812qIbznophrTcsI7Y0C8Dp8kkTtfCA E60CTVHNqYOoxdve4HfXkTOcyPouC27PD9o3FHLvaUe/i9AephMsCc2iFTIxrbrfxlRjqBJ3AKf ALlmVoQJLJ8qVYdObvlFWEwca3w4U5uriFdM1Bv/jxJDUku2PNn5ErfRqpilVnSPw4pGdVDzySB 7JjVu4s5AGlbCowyWPfX1pd2kUMFQeP8uAVlDOHDPDkSOzeDWWJNtuyL6mpIX01TdrRxjjBjgI4 20cElJ6KNGOL5V2Wq2BLdWNzj2mydHhpYvL3lVb3Rsiu0rmMfw38FNTll9lElAoBBK61BhcaRjb XhTUhELqVbkBfZtspWZIGcO+fnsQuI4dUviLh3W5kfgtJfb41eyVOVUfUmM3dEG7y+D7o5CoYOC pJS88oOk7DBhP11iA/gCuOROJwrK1DfGM6db7X27hbmASKcrpU3rOnQwllEN4kU/OpdqNBP7Uee eJTNUtlvvwUPXvNzSQ142YgBOGlB8tmNEYF19BX39j8VcpJxErHkgIan9a0bII+BcngqQ83reUA acm79GI7V0zOMkhscJtfy1nC0pS4Yh4UkkUHv6N8gNWZeeA6r4X/8yfdrbDgCDtCi7J/82jrsPR lsKFYUqFhJBWo86IzI1QAmPB9dMEOLhduXbFCIsKNaNh88CQKaRmDCmXszcwplGJ7NxS0/zxv3B HddpWPiomgTTbCG6621Vwa95NI7hhaFskSWDqlGudLLtRO1utO1W2zFTsGD7I4Jc8uXNa5VVhlE sbz+nTtSZ+0xX/jlDgcBvT2FuRt9RuginVBtWeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 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, 03 May 2019 18:08:08 -0000

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.