Re: New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

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*