Hi Yao Yes there would be a way to tell the virtual instances apart from routing protocol perspective exactly as you stated could be different router-id and virtual / sub ports similar to line card case where each line card is a different virtual routing instance.
Here are the MSD cases discussed that I can think of .. Per node Per slot virtual routing instance Logical Virtual instance with sub ports Per Link Interesting though as Les brought up that RFC 9088 that ERLD-MSD seems to be at the node level in that if a router has multiple interfaces it will take the lowest ERLD-MSD across all interfaces instead of advertising ERLD-MSD for each of the individual interfaces. Thanks Gyan On Tue, Aug 29, 2023 at 5:31 AM <[email protected]> wrote: > Hi Gyan, > > > If I understand you right, in the virtualization scenario, eventually > there would be some way to tell virtual routing instances apart from the > routing protocol's perspective, either they can be treated as different > routers with different router ID (taking OSPF as an example), or they share > the same routing protocol instance, but own different virtual/sub ports, > similar as the line card case. In the first case, the per-node MSD is > applicable, in the latter case, the per-link MSD would work. > > Is there a third situation? > > > Thanks, > > Yao > Original > *From: *GyanMishra <[email protected]> > *To: *Tony Li <[email protected]>; > *Cc: *Les Ginsberg <[email protected]>;刘尧00165286;[email protected] < > [email protected]>;mpls <[email protected]>; > *Date: *2023年08月29日 11:03 > *Subject: **Re: [Lsr] New Version Notification for > draft-liu-lsr-mpls-inspection-msd-01.txt* > > Hi Tony > > Would the granularity you would want for the modular node that is now > virtualized into virtual routing instances be on per routing instance > level. > > Each vendor has a different flavor of how this virtualization is done. > > So the MSD capability would be at that level. > > Kind Regards > > Gyan > On Mon, Aug 28, 2023 at 10:36 PM Tony Li <[email protected]> wrote: > >> >> 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, <[email protected]> <[email protected]> >> 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 >> Original >> *From: *LesGinsberg(ginsberg) <[email protected]> >> *To: *刘尧00165286;[email protected] <[email protected]>;[email protected] <[email protected] >> >; >> *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 <[email protected]> *On Behalf Of * [email protected] >> *Sent:* Monday, August 28, 2023 12:33 AM >> *To:* [email protected]; [email protected] >> *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: *[email protected] <[email protected]> >> >> *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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
