Re: [mpls] draft-andersson-mpls-mna-fwk

Tony Li <tony.li@tony.li> Wed, 08 June 2022 17:17 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB45C14F738 for <mpls@ietfa.amsl.com>; Wed, 8 Jun 2022 10:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.507
X-Spam-Level:
X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GfYxq20t6FL for <mpls@ietfa.amsl.com>; Wed, 8 Jun 2022 10:17:54 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EADC14F718 for <mpls@ietf.org>; Wed, 8 Jun 2022 10:17:54 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id a10so19170308pju.3 for <mpls@ietf.org>; Wed, 08 Jun 2022 10:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=svrB4jGvrWa8cJxc5QPrEahyiw7C6RmuFV/XIm8QHfI=; b=W+OiEza5gZYJsD7VGMAtpdPqCFvYMaHiVyTaKHn+mml4CAwGqD8E7DA0h9hqccalXS SXUtWVK7s0HykuoUMs5jiW/0Cu6uDuZ8wxezW0GwpLNqn93fpzX4yy97iY8OnZije5bu QCmGoX2yAmYXMAs5kpQONQQrTHYG3a8OBhzvFybTju45E0DFfT76B30mmY2/1W6Jopjl gx7gn8ga3ELf70W2MHz3oDaifu4TyqEeaUo/s3IlEAW8Jc0xrtpNArIv7Se4aYmHhKew nA1wAUItHpSrfG6xkL4JJHjhFSK7Jk1phxdsCnFHotWJZ5CBw37l9zftWh4mIjn2uny2 Uv2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=svrB4jGvrWa8cJxc5QPrEahyiw7C6RmuFV/XIm8QHfI=; b=wTZk+GeWahyAfFHTV23uZOvSPMB3stawF7PxxjqSdXpOgDeGNQOGcfwfmYcTBwfiFA uRZc40355cRoMJ3D36jFnt7kaS3EWV1e8HvpTn4QhYELEl8u7bow4ASeESMDRjkQWKnp g3lBSOk3HvbDU9YArz7h95H6AAzoT7OVbepgV1MalhI7yQ7LimQPi9IuhNp3bkCAb5Zx Yd6E95n7ivrXXeG2k7ZgGTWfyRgHMdIoUaOfJUp0ETLkxDs8siDoTzUFvbOFWvSeBZVD aiTCzQcEMeTTOPeWerqSwtJQbrfTD1UTkw+VZRIYQd1B9VNqNRqtqmQVx/m7xE1LWqkB i2bw==
X-Gm-Message-State: AOAM530E1L/tMgrR7xxfEMNEi5Ie8IemTXal7KE6iAuDj+aY6vWOS3Yy fIb462UXNUZMAgOPirswErQ=
X-Google-Smtp-Source: ABdhPJyRYrCLYzaivd0yJnB3RylXR15q86tk89GNa0VZV5d/CuwcZvDWARcoGB3pJYcDDPFjyZ/o5A==
X-Received: by 2002:a17:90b:4c4a:b0:1e3:3b3:8800 with SMTP id np10-20020a17090b4c4a00b001e303b38800mr261136pjb.6.1654708673035; Wed, 08 Jun 2022 10:17:53 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id y129-20020a636487000000b003faf4acac63sm15107144pgb.13.2022.06.08.10.17.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jun 2022 10:17:50 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <C05F145D-9792-4BEE-8560-4BA0A58F6539@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC155AE2-8F02-448A-9FD4-39C1FB935D59"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Wed, 08 Jun 2022 10:17:49 -0700
In-Reply-To: <6839_1654697978_62A0AFFA_6839_46_1_e76c4078f46449e3b127bb647052f861@orange.com>
Cc: mpls <mpls@ietf.org>
To: bruno.decraene@orange.com
References: <6839_1654697978_62A0AFFA_6839_46_1_e76c4078f46449e3b127bb647052f861@orange.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/hGXOqOLnKzZvhv5vLGo_9A2hpjg>
Subject: Re: [mpls] draft-andersson-mpls-mna-fwk
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2022 17:17:56 -0000

Hi Bruno,

Thank you for your comments.


> "2.2.  Partial Processing
> 
>   Legacy devices that do not recognize the MNA label will discard the
>   packet as described in [RFC3031]."
> 
> IINM, 
> - at this point in the draft the term "MNA label" is not defined. It is defined latter in the doc (§3.1). One option would be to introduce the term in section "2 Structure". Any other option a priori  works for me.


I’ve added it to the definition of NSI in section 1.2.1.


> - RFC3031 specifies that the packet be discarded iif that MNA label is the top label being looked up. So unless we always put the MNA label on top (which does not seem like the plan), such packet drop would only happen on the egress LER.


Not necessarily.  MNA could be inserted anywhere in the label stack, not just at the bottom of stack, so it could conceivably come to the top of stack before the egress. 


> Proposed NEW: As described in [RFC3031], legacy devices that do not recognize the MNA label will discard the packet if the incoming label (top label) is the MNA label . This may typically happen on the LER but not on transit LSR."


I’ve taken your first sentence, slightly morphed.

	As described in [RFC3031], legacy devices that do not recognize the
	MNA label will discard the packet if the top label is the MNA label.


> --
> " 3.1.  The MNA Label
> 
>   The first LSE in a network action sub-stack contains a special label
>   that indicates a network action sub-stack."
> 
> So the "first LSE in a network action sub-stack" is defined as the MNA.


The first LSE is defined as the NSI.


> In which case, I don't think I agree with §3.2 as in case of PHP, the egress LER sees that first LSE (the MNA label) as the incoming label and hence uses the TLL and TC as per their original meaning.
> " 3.2.  TC and TTL
> 
>   In the first LSE of the network action sub-stack, only the 20 bits of
>   Label Value and the Bottom of Stack bit are significant, the TC field
>   (3 bits) and the TTL (8 bits) are not used.  This leaves 11 bits that
>   could be used for other purposes."


Per section 2.4:

   A network action sub-stack should never occur at the top of the MPLS
   label stack.  A node that is responsible for popping a forwarding
   label immediately above a network action sub-stack must also pop any
   network action sub-stacks that immediately follow.

So even in the case of PHP, the NAS should never come to the top of stack.  Since it’s never at the top of stack, no system should be using the TC and TTL fields.


> --
> I also have one open question for §3.5.  Encoding a Network Action
> 
> MPLS is used within in closed domain. So in theory the bit catalog/operation codes could be defined as "Private Use" rather than as global IANA allocated.


Theoretically true.  However, the more things are relegated to a ‘limited domain’ and not standardized, the less and less we can all benefit from having common standards.  If you want to have a network where you have to manually configure every code point in every field in every packet, you COULD do that.  I don’t want to live that way and I don’t think most other people do either. Standards are good. That’s why we’re here. :)


> There is pro & con on both options but clearly for the former the number of codes/bit would be smaller hence this would possibly favour bit catalogs.


I’m sorry, I’m not following this.  The encoding should be independent of the number of defined network actions.


> I would be interested in some text about this and the related trade-off. (could be very short, just like the discussion on bit vs codes.)


Please send text. :)


> I'm not sure that [RFC3031) has requirements for LSE which are not a the top of the stack. However, it's probably safer to forbid NAS to use values 0-15 in the "label" part of the LSE, in order to avoid an LSR scanning the whole stack wrongly recognize a wrong bSPL (e.g. EL or the MAN label). If so I think it should be indicated in this document.


This is why MNA should never be sent through systems that don’t recognize MNA.  They could easily interpret AD as ELI, for example.

I understand the restriction that you’re suggesting, but I don’t think we want to go that far.  It grossly limits what we can do with AD.


> Typo :s/shoukd/should


Fixed, thank you.

Changes queued for the next revision.

Regards,
Tony