Re: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Shraddha Hegde]

I am not aware of any undisclosed IPR related to this document.

Rgds
Shraddha



Juniper Business Use Only
From: Dhamija, Amit 
Sent: Tuesday, August 29, 2023 8:38 AM
To: Acee Lindem ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr 
Subject: Re: IPR Poll for Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)

[External Email. Be cautious of content]

Hi Acee,

I'm not aware of any undisclosed IPR.
Brgds
Amit D
Rakuten
From: Acee Lindem mailto:acee.i...@gmail.com>>
Date: Thursday, 24 August 2023 at 1:32 AM
To: 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
 
mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>
Cc: lsr mailto:lsr@ietf.org>>
Subject: IPR Poll for Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)
[EXTERNAL] This message comes from an external organization.

Co-Authors,

Are you aware of any IPR that applies to 
draft-posenak-lsr-igp-ureach-prefix-announce-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are a few IPR statements already - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Also, since there are nine authors, it would be great if you could reduce the 
author list and make
the others contributors (which still requires an IPR response).

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Dhamija, Amit]

Hi Acee,

I'm not aware of any undisclosed IPR.

Brgds
Amit D
Rakuten
From: Acee Lindem 
Date: Thursday, 24 August 2023 at 1:32 AM
To: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 

Cc: lsr 
Subject: IPR Poll for Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)
[EXTERNAL] This message comes from an external organization.

Co-Authors,

Are you aware of any IPR that applies to 
draft-posenak-lsr-igp-ureach-prefix-announce-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are a few IPR statements already - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Also, since there are nine authors, it would be great if you could reduce the 
author list and make
the others contributors (which still requires an IPR response).

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

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  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,  
> 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) 
> *To: *刘尧00165286;m...@ietf.org ;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  *On Behalf Of * liu.ya...@zte.com.cn
> *Sent:* Monday, August 28, 2023 12:33 AM
> *To:* m...@ietf.org; 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 
>
> *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
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

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,   
> 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) 
> To: 刘尧00165286;m...@ietf.org ;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  On Behalf Of liu.ya...@zte.com.cn
> Sent: Monday, August 28, 2023 12:33 AM
> To: m...@ietf.org; 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>>
> 
> 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

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

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

[liu.yao71]

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) 
To: 刘尧00165286;m...@ietf.org ;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  On Behalf Of liu.ya...@zte.com.cn
 Sent: Monday, August 28, 2023 12:33 AM
 To: m...@ietf.org; 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 



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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Gyan Mishra]

I support adoption and not aware of any undisclosed IPRs.

This draft is extremely valuable for SRv6 locator summarization in multi
area / multi level networks and being able to used for BGP PIC edge
activation by tracking BGP next hop reachability via UPA.

As SRv6 uses the IPv6 data plane this can be useful in any native IPv4 or
IPv6 network.

This draft can also be useful for MPLS inter area extension RFC 5283 so LPM
summarization can work and being able to track the component prefixes.

In the latest update two new flags were added to the draft to signal UPA.

Thank you

Gyan

On Wed, Aug 23, 2023 at 4:07 PM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Daniel,

> [DV] No, there’s no need to leak and advertise

You mean there is no need for RFC9352 in your network. If so - great.

I was however asking the question: if network needs to advertise any of the
information defined in RFC9352 would it still benefit from UPA ?

Thx,
R.



On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel  wrote:

> Hi Robert, inlines
>
>
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Monday, August 28, 2023 at 12:00 PM
> *To: *"Hassan, Shehzad" , Daniel
> Bernier 
> *Cc: *lsr , "
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" <
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable
> Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
> (Fixed draft name)
>
>
>
> Hi Shehzad & Daniel,
>
>
>
> I support this work as it is key for summarization in an SRv6/IPv6 network.
>
>
>
> Are you not going to advertise and leak across your IGP domain any of the
> SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/
> for the PEs ?
>
> [DV] No, there’s no need to leak and advertise. For an SRv6 network, we
> are summarizing locators and loopback (should be derived from locator 0).
> This makes the routing domain “opaque”.
>
>
>
> And if you do, is there still some use case for UPA ?
>
>
>
> Perhaps I am missing something but how would those extensions survive
> summarization ?
>
>
>
>
>
> Thx,
> Robert
>
> Cheers,
>
> Dan
>
>
>
> > On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> >
> > LSR Working Group,
> >
> > This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> > Please indicate your support or objection on this list prior to
> September 7th, 2023.
> >
> > Thanks,
> > Acee
> >
> --
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Voyer, Daniel]

Hi Robert, inlines


From: Lsr  on behalf of Robert Raszuk 
Date: Monday, August 28, 2023 at 12:00 PM
To: "Hassan, Shehzad" , Daniel Bernier 

Cc: lsr , "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" 

Subject: [EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)

Hi Shehzad & Daniel,

I support this work as it is key for summarization in an SRv6/IPv6 network.

Are you not going to advertise and leak across your IGP domain any of the SRv6 
extensions as described in https://datatracker.ietf.org/doc/rfc9352/ for the 
PEs ?
[DV] No, there’s no need to leak and advertise. For an SRv6 network, we are 
summarizing locators and loopback (should be derived from locator 0). This 
makes the routing domain “opaque”.

And if you do, is there still some use case for UPA ?

Perhaps I am missing something but how would those extensions survive 
summarization ?


Thx,
Robert
Cheers,
Dan

> On Aug 23, 2023, at 4:07 PM, Acee Lindem 
> mailto:acee.i...@gmail.com>> wrote:
>
> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023.
>
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Luay Jalil]

I support Working Group adoption

Regards,
Luay

On Wed, Aug 23, 2023 at 3:07 PM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Dhamija, Amit]

Hi Acee and WG,

IGP UPA is imperative to solve the BGP PIC convergence problem in an SRv6 
deployment with prefix summarization.

>From Rakuten's side, we support the adoption of the draft.

Brgds
Amit D
Rakuten

From: Acee Lindem 
Date: Thursday, 24 August 2023 at 1:37 AM
To: lsr 
Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 

Subject: Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)
[EXTERNAL] This message comes from an external organization.

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Hi Shehzad & Daniel,


> I support this work as it is key for summarization in an SRv6/IPv6 network.
>

Are you not going to advertise and leak across your IGP domain any of the
SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/
for the PEs ?

And if you do, is there still some use case for UPA ?

Perhaps I am missing something but how would those extensions survive
summarization ?


Thx,
Robert


> On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> >
> > LSR Working Group,
> >
> > This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> > Please indicate your support or objection on this list prior to
> September 7th, 2023.
> >
> > Thanks,
> > Acee
> >
> --
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Hassan, Shehzad]

I support this work as it is key for summarization in an SRv6/IPv6 network.

Shehzad Hassan
Bell Canada



> On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Kamran Raza (skraza)]

I support the adoption of this key draft as it helps achieve BGP PIC along with 
IP prefix summarization in SRv6 networks.
--
Kamran

From: Lsr  on behalf of Hassen, Clayton 

Date: Monday, August 28, 2023 at 10:18 AM
To: Acee Lindem 
Cc: lsr , draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 

Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)
I support.

This is a key requirement for large scale deployment models using summarization 
in SRv6 networks

—CH

> On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
>
> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023.
>
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Hassen, Clayton]

I support.

This is a key requirement for large scale deployment models using summarization 
in SRv6 networks

—CH

> On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call IPR Poll for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

[Antoni Przygienda]

Unaware of undisclosed IPR



Juniper Business Use Only

From: Gunter van de Velde (Nokia) 
Date: Monday, 28 August 2023 at 11:56
To: Acee Lindem , 
draft-ietf-lsr-isis-fast-flood...@ietf.org 

Cc: lsr 
Subject: RE: WG Last Call IPR Poll for "IS-IS Fast Flooding" - 
draft-ietf-lsr-isis-fast-flooding-04
[External Email. Be cautious of content]

I am unaware of any undisclosed IPR.

G/

From: Acee Lindem 
Sent: Thursday, July 20, 2023 1:20 AM
To: draft-ietf-lsr-isis-fast-flood...@ietf.org
Cc: lsr 
Subject: WG Last Call IPR Poll for "IS-IS Fast Flooding" - 
draft-ietf-lsr-isis-fast-flooding-04


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Authors,



A cornucopia of IPR declarations have already been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-isis-fast-flooding

Are you aware of any additional IPR that applies to 
draft-ietf-lsr-isis-fast-flooding-04.

If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not been disclosed in conformance with IETF rules.




Thanks,

Acee





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

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of liu.ya...@zte.com.cn
Sent: Monday, August 28, 2023 12:33 AM
To: m...@ietf.org; 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>>
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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Hi Peter,

> The version -04 does not contain normative MUST that UPA shall only be
> > used to trigger invalidation when end to end encapsulation is used for
> > subject application(s). So as written is in fact quite undeployable in a
> > mixed vendor and legacy node(s) environment doing hop by hop routing. We
> > can't just hope that this is all about configuring the network in a
> > proper way.
>
> above looks more like a comment that can easily be addressed by
> additional text, which I'm willing to add, rather than an objection to
> draft becoming a WG document. Please let me know if you think otherwise.
>

Ok if you are willing to add such restriction to the spec then I can remove
my concern #1.

> The solution is too pragmatic ...
>
> Isn't that a good thing, isn't it? :)
>

:)

Yes and it does assure that we can have some mechanism like this before
we all retire !

But you know once you have an interim solution it is much harder to
convince
folks to work on a more optimal one.


> It does not look at the problem
> > holistically. Yes I still think the problem is worth solving but outside
> > of link state IGP doing UPA blast flooding everywhere domain wide even
> > if no nodes need that info. As discussed at length it could be done via
> > either BGP indirection or via PUB-SUB model (as proposed).
>
> I don't object to solve this problem in BGP, or elsewhere. But given
> that the problem we are trying to solve is created by the IGP
> summarization and the ultimate source of the prefix reachability or
> unreachibility comes from IGPs, having a solution in IGPs seems like a
> natural choice.


That is all correct. But I really do not like to use domain wide flooding
for it.

For example if you would contain the solution within IGP but from local or
remote
ABRs unicast by UDP to subscribers that given PE or POP is down that would
also
contain the solution to IGP.  Yes it is a bit more difficult as you would
need to solve
subscription problem first as opposed to the blast or spray approach, but
the current draft
does not even leave any room for such apparatus.

So my concern here is not that the proposal is broken. It is just
suboptimal IMHO.

And as we spoke a few weeks back in SF I think it is harmless, but is this
enough ?

Lastly, I think PEs do not accidentally go down that often, and for any
planned
maintenance there are other ways to drain the box.

With that said, consider my objection to be a soft one based on the above.

Cheers,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Ketan Talaulikar]

Hi Acee/All,

I support the adoption of this document by the WG. Several WG members have
been actively involved in the development of this document for over a year
now. The authors have included the feedback and as a result the solution
has evolved very well.

While there is another document [1] that tries to address the same problem
statement, the solution in there is still not workable despite the feedback
provided to its authors over the years. We need a workable IGP based
solution.

Overall, I find that the solution in draft-ppsenak:
- is an IGP based solution and therefore in the charter or LSR WG
- is a backward compatible solution that does not break existing IGP
deployments running older software versions; it allows for incremental
deployment/rollout
- includes explicit indication of UPA which is more robust and more
appropriate semantically

Given that the problem scenario is well acknowledged, there is running code
for this solution, and we have feedback from operators who are interested
in deploying this solution, I believe it is the time for the WG to adopt
this document.

Thanks,
Ketan

[1]
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/


On Thu, Aug 24, 2023 at 1:37 AM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Bernier, Daniel]

Hi all, 

I support working group adoption

Dan Bernier

On 2023-08-23, 4:07 PM, "Acee Lindem" mailto:acee.i...@gmail.com>> wrote:


LSR Working Group,


This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 


Thanks,
Acee
--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints





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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Voyer, Daniel]

Hi wg,

I support the adoption of UPA. This solution is key when summarization is used 
for IPv6/SRv6 networks.

Thanks
Dan

On 2023-08-23, 3:58 PM, "Lsr on behalf of Acee Lindem" mailto:lsr-boun...@ietf.org> on behalf of acee.i...@gmail.com 
> wrote:


LSR Working Group,


This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 


Thanks,
Acee 
___
Lsr mailing list
Lsr@ietf.org 
https://www.ietf.org/mailman/listinfo/lsr 

--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints



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

Re: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name and IPR link)

[Voyer, Daniel]

Hi Acee,

I am not aware of any IPR regarding this work.

Cheers,
Dan

On 2023-08-23, 4:06 PM, "Acee Lindem" mailto:acee.i...@gmail.com>> wrote:


Co-Authors, 


Are you aware of any IPR that applies to 
draft-posenak-lsr-igp-ureach-prefix-announce-04? 
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).


There is one IPR statement - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ppsenak-lsr-igp-ureach-prefix-announce
 



If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.


If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.


Also, since there are nine authors, it would be great if you could reduce the 
author list and make
the others contributors (which still requires an IPR response). 


Thanks,
Acee
--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints





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

Re: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Peter Psenak]

Hi Acee,

I'm not aware of any undisclosed IPR.

thanks,
Peter

On 23/08/2023 13:02, Acee Lindem wrote:

Co-Authors,

Are you aware of any IPR that applies to 
draft-posenak-lsr-igp-ureach-prefix-announce-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are a few IPR statements already - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Also, since there are nine authors, it would be great if you could reduce the 
author list and make
the others contributors (which still requires an IPR response).

Thanks,
Acee


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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Peter Psenak]

Hi Robert,

please see inline:

On 23/08/2023 14:48, Robert Raszuk wrote:

Dear LSR WG,

I object on two basis ...

1)

The version -04 does not contain normative MUST that UPA shall only be 
used to trigger invalidation when end to end encapsulation is used for 
subject application(s). So as written is in fact quite undeployable in a 
mixed vendor and legacy node(s) environment doing hop by hop routing. We 
can't just hope that this is all about configuring the network in a 
proper way.


above looks more like a comment that can easily be addressed by 
additional text, which I'm willing to add, rather than an objection to 
draft becoming a WG document. Please let me know if you think otherwise.





2)

The solution is too pragmatic ... 


Isn't that a good thing, isn't it? :)

It does not look at the problem 
holistically. Yes I still think the problem is worth solving but outside 
of link state IGP doing UPA blast flooding everywhere domain wide even 
if no nodes need that info. As discussed at length it could be done via 
either BGP indirection or via PUB-SUB model (as proposed).


I don't object to solve this problem in BGP, or elsewhere. But given 
that the problem we are trying to solve is created by the IGP 
summarization and the ultimate source of the prefix reachability or 
unreachibility comes from IGPs, having a solution in IGPs seems like a 
natural choice.


thanks,
Peter



Regards,
Robert


On Wed, Aug 23, 2023 at 10:07 PM Acee Lindem > wrote:


LSR Working Group,

This begins the working group adoption call for “IGP Unreachable
Prefix Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to
September 7th, 2023.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org 
https://www.ietf.org/mailman/listinfo/lsr




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

Re: [Lsr] WG Last Call IPR Poll for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

[Gunter van de Velde (Nokia)]

I am unaware of any undisclosed IPR.

G/

From: Acee Lindem 
Sent: Thursday, July 20, 2023 1:20 AM
To: draft-ietf-lsr-isis-fast-flood...@ietf.org
Cc: lsr 
Subject: WG Last Call IPR Poll for "IS-IS Fast Flooding" - 
draft-ietf-lsr-isis-fast-flooding-04


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Authors,



A cornucopia of IPR declarations have already been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-isis-fast-flooding

Are you aware of any additional IPR that applies to 
draft-ietf-lsr-isis-fast-flooding-04.

If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not been disclosed in conformance with IETF rules.



Thanks,

Acee




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

[Lsr] Fw: New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[liu.yao71]

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 
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