Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

Loa Andersson <> Wed, 13 May 2020 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E4A83A0D2E; Tue, 12 May 2020 20:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LJnbzBPQgfRT; Tue, 12 May 2020 20:52:03 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D6A33A09C0; Tue, 12 May 2020 20:52:01 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 84B12321F3F; Wed, 13 May 2020 05:51:58 +0200 (CEST)
To: "Ketan Talaulikar (ketant)" <>, "" <>
Cc: "" <>, "" <>
References: <> <>
From: Loa Andersson <>
Message-ID: <>
Date: Wed, 13 May 2020 11:51:54 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam
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: Wed, 13 May 2020 03:52:06 -0000


Anything of this that need to addressed before wg adoption?


I leave the wgap opeb a few extra days to llow you to respond to this.


On 12/05/2020 23:32, Ketan Talaulikar (ketant) wrote:
> Hello Authors,
> I have the following comments on this draft and would be good if you could clarify/respond.
> 1)The FEC description should match the "context" that is advertised in the control plane for Peer Adj SID. E.g. the local/remote Interface IDs are not being included from
> 2) For the Peer Node SID, the control plane definition is and the FEC description in this draft is not aligned with the corresponding control plane. The Peer Node SID is meant for the packet to be delivered to a specific BGP peer and it does not matter over which interface it is received. So why have those interface addresses as mandatory in the FEC. The only thing the control plane indicates is the peering session itself.
> 3) Same as (2) above, for the Peer Set SID, the interfaces are don't care.
> 4) The draft just says that the procedures are borrowed from RFC8287 but I don't think this is so straightforward or trivial. E.g. has the following:
>     The network node that is immediately downstream of the node that
>     advertised the Adjacency Segment ID is responsible for generating the
>     FEC Stack Change sub-TLV for POP operation for the Adjacency Segment
>     ID.
> In the case of IGPs, the downstream node does have the label and context for adjacency SID (which is functionally closest to BGP EPE SIDs). In the BGP-EPE SIDs case, this is not always the case. So I believe, it would be better if the entire operation were described.
> 5) The ping or traceroute done to any of the BGP EPE SID corresponding to an eBGP session may result in the packet being sent to another entity. The security consideration talk about it, but the problem is not addressed by the remote AS dropping the packets. The security issue is that the OAM packet could expose the FECs and information of the local AS to a remote AS. So it is more as an caveat for the operators performing the OAM operation to be mindful of this fact.
> In general, some more description that set the stage for the introduction of the new extensions and elaborate more on the operations (some considerations above on what is mandatory to evaluate and what is optional).
> Thanks,
> Ketan
> -----Original Message-----
> From: mpls <> On Behalf Of Loa Andersson
> Sent: 30 April 2020 08:26
> To:
> Cc:;
> Subject: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam
> Working Group,
> This is to start a two week poll on adopting draft-hegde-mpls-spring-epe-oam as a MPLS working group document.
> Please send your comments (support/not support) to the mpls working group mailing list ( Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document.
> There is one IPR disclosure against this document.
> The authors have stated on the MPLS wg mailing list that they are unaware of any IPRs that relates to this document.
> The working group adoption poll ends May 15, 2020.
> /Loa


My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use

Loa Andersson                        email:
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64