I am in agreement with Tony.
It seems that there are potential use cases for link specific RLD.

As to why RFC 9088 chose to prohibit use of link specific ERLD, the authors of 
that RFC are in the best position to answer.
One possible explanation is “simplicity”. This aspect is discussed in 
https://www.rfc-editor.org/rfc/rfc8662.html#name-entropy-readable-label-dept – 
but RFC 9088 does not make explicit if that was the reason – so I am only 
speculating here.

Yao – I think this deserves discussion in MPLS WG.
At a minimum, if the conclusion is to ignore per Link RLD advertisements that 
needs to be made explicit (as RFC 9088 did) and some explanation as to “why” 
should be included in the draft.

   Les



From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li
Sent: Tuesday, August 29, 2023 7:15 AM
To: liu.ya...@zte.com.cn
Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; mpls <m...@ietf.org>; 
lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-liu-lsr-mpls-inspection-msd-01.txt


Hi Yao,

IMHO, that was a mistake in the specification of ERLD.

I’m hopeful that we don’t repeat the same mistake.

Tony



On Aug 29, 2023, at 1:22 AM, 
<liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> 
<liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> wrote:


Hi Tony,



Thanks a lot for your suggestion. This scenario would be taken into 
consideration.

But on the other hand, what I haven't understood is that why ERLD-MSD is 
limited to per-node scope considering that each line card may have different 
capabilities to read through the label stack.



Best Regards,

Yao
Original
From: TonyLi <tony...@tony.li<mailto:tony...@tony.li>>
To: 刘尧00165286;
Cc: Les Ginsberg <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>;mpls 
<m...@ietf.org<mailto:m...@ietf.org>>;lsr@ietf.org 
<lsr@ietf.org<mailto:lsr@ietf.org>>;
Date: 2023年08月29日 10:36
Subject: Re: [Lsr] New Version Notification for 
draft-liu-lsr-mpls-inspection-msd-01.txt

Hi Yao,
Please consider the case of a modular node with a number of different line 
cards, where the line cards are based on different forwarding engines.

RLD needs to be link specific.

Regards,
Tony



On Aug 28, 2023, at 6:55 PM, 
<liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> 
<liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> wrote:


Hi Les,

Thanks a lot for your review and comments.

This new MSD is a per-node capability just like ERLD-MSD, mainly because it 
represents how many MPLS labels the node can read, and it is not related with 
the links.

And the description in this draft you mentioned is written taking example by 
RFC9088(section 4. Advertising ERLD Using IS-IS).

I'll explicitly state the scope of the new MSD in the next version.



Best Regards,

Yao


_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

From: LesGinsberg(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
To: 刘尧00165286;m...@ietf.org <m...@ietf.org<mailto:m...@ietf.org>>;lsr@ietf.org 
<lsr@ietf.org<mailto:lsr@ietf.org>>;
Date: 2023年08月28日 20:57
Subject: RE: [Lsr] Fw: New Version Notification for 
draft-liu-lsr-mpls-inspection-msd-01.txt
Yao –

Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with per-link 
scope and per-node scope.

Your draft only states:

“If a router has multiple interfaces with different capabilities of
   reading the maximum label stack depth, the router MUST advertise the
   smallest value found across all its interfaces.”

This suggests that you intend only to advertise a per-node capability – but as 
you don’t explicitly state that – and you don’t provide a reason why a per link 
capability isn’t applicable, I am unclear as to what your intentions are here.

Could you clarify whether you intend to support both per link and per node 
capability – and if not why not?

Thanx.

   Les


From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of 
liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>
Sent: Monday, August 28, 2023 12:33 AM
To: m...@ietf.org<mailto:m...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Fw: New Version Notification for 
draft-liu-lsr-mpls-inspection-msd-01.txt


Hi All,

A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.

In this document, a new type of MSD is defined to reflect the Readable Label 
Depth(RLD), which helps in the MPLS MNA solution.

In this version, the main update is that some description is added to explain 
why a new MSD is preferred instead of the ERLD-MSD.

Currently this new MSD is called Base MPLS Inspection MSD, it may be changed to 
a more straightforward name like RLD-MSD based on the description in the MNA 
architecture/solution document.

Your comments and suggestions are more than welcome!



Thanks,

Yao
Original
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: 2023年08月28日 14:55
Subject: New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt
A new version of Internet-Draft draft-liu-lsr-mpls-inspection-msd-01.txt has
been successfully submitted by Yao Liu and posted to the
IETF repository.

Name:     draft-liu-lsr-mpls-inspection-msd
Revision: 01
Title:    Signaling Base MPLS Inspection MSD
Date:     2023-08-27
Group:    Individual Submission
Pages:    7
URL:      
https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.txt
Status:   https://datatracker.ietf.org/doc/draft-liu-lsr-mpls-inspection-msd/
HTML:     
https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-liu-lsr-mpls-inspection-msd
Diff:     
https://author-tools.ietf.org/iddiff?url2=draft-liu-lsr-mpls-inspection-msd-01

Abstract:

   This document defines a new type of MSD, Base MPLS Inspection MSD to
   reflect the Readable Label Depth(RLD), and the mechanism to signal
   this MSD using IGP and BGP-LS.



The IETF Secretariat





_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to