Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Oct 2020 11:08:31 +0800

Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again along your original question.

Please see inline.[WAJ]

-----Original Message-----                                                                                                                                              
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; 'Aijun Wang' <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun, 

Other than your ill-conceived topology discovery heuristic

[WAJ] The topology discovery heuristic is not suitable for the corner use case when the unnumbered interface is used, as explained in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B.  If you don’t agree, would you like to illustrate other non-applicable scenarios?

what other possible reason would there be for associating the passive attribute with a prefix? 

[WAJ] To know the boundary of the IGP domain. After knowing the boundary, the controller can safely apply and check the network security policy, the inbound traffic control policy etc.

Thanks,

Acee

On 9/29/20, 10:39 PM, "Aijun Wang" < <mailto:[email-masked]> [email-masked]> wrote:

    Hi, Acee and Peter:

    Passive interface is mainly used at the edge of the network, where the unnumbered interface will not be used. 

    And the information to flag the passive interfaces is for positioning the area boundary, not conflict with the abstract capabilities of the area inside.

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Acee Lindem (acee)

    Sent: Tuesday, September 29, 2020 9:16 PM

    To: Peter Psenak < <mailto:ppsenak=[email-masked]> ppsenak=[email-masked]>; Aijun Wang < <mailto:[email-masked]> [email-masked]>; 'Aijun Wang' < <mailto:[email-masked]> [email-masked]>

    Cc:  <mailto:[email-masked]> [email-masked]

    Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

    Speaking as WG member:

    Hi Aijun, Peter, 

    I agree with Peter - one of the main motivations for having areas is to abstract the topology within the area. Now you're trying to supplant this  - one topological detail at a time with ill-conceived IGP features.

    Thanks,

    Acee

    On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" < <mailto:[email-masked]%20on%20behalf%20of%20ppsenak=[email-masked]> [email-masked] on behalf of ppsenak=[email-masked]> wrote:

        Hi Aijun,

        On 29/09/2020 11:07, Aijun Wang wrote:

        > Hi, Peter:

        > Thanks for your comments.

        > 1. For BGP-LS deployment, there normally only be one router that within the

        > IGP domain to report the topology information, this router should know such

        > passive links which exists mainly on other border routers via the IGP

        > protocol. This is main reason to extension the IGP protocol. > 2. For the solution, normally, the link within the IGP connect two 

        ends, but

        > passive interface is special and not fall in this space. We have studied the

        > current TLVs that for link, and find no suitable container to append this

        > information. This is the reason that we select the TLVs that associated with

        > Prefix.

        if the link is unnumbered, your solution does not work. As I said, if 

        you need a knowledge about the link, you can not advertise it as a prefix.

        thanks,

        Peter

        >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix LSA", which

        > isolate the prefix information that associated with link into this

        > container, contains the stub link, local interface information etc. Put such

        > attribute along with the prefix is then acceptable?

        > Best Regards

        > Aijun Wang

        > China Telecom

        > -----Original Message-----

        > From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Peter

        > Psenak

        > Sent: Tuesday, September 29, 2020 4:29 PM

        > To: Aijun Wang < <mailto:[email-masked]> [email-masked]>

        > Cc:  <mailto:[email-masked]> [email-masked]

        > Subject: Re: [Lsr] FW: New Version Notification for

        > draft-wang-lsr-passive-interface-attribute-04.txt

        > Hi Aijun,

        > here's my comments:

        > The purpose of this draft is to advertise passive links.

        > 1. I'm not sure the problem needs to be solved by IGPs. I tend to believe

        > ietf-idr-bgpls-inter-as-topology-ext is sufficient.

        > 2. the solution that you proposed is wrong. You are trying to derive

        > topological data about the passive links from the prefix advertisement.

        > This is semantically incorrect and only works under very specific condition.

        > If you need to advertise a link, advertise it as a "special"

        > link, not as a "special" prefix.

        > thanks,

        > Peter

        > On 29/09/2020 03:17, Aijun Wang wrote:

        >> Hi, Peter:

        >> Would you like to review and give comments on the updates version of this

        > draft?

        >> We have also added the protocol extension proposal for OSPFv3.

        >> The update version of this draft can refer to

        >>  <https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface

        >> -attribute

        >> Thanks in advance.

        >> Best Regards

        >> Aijun Wang

        >> China Telecom

        >>> -----Original Message-----

        >>> From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]]

        >>> Sent: Monday, September 28, 2020 3:17 PM

        >>> To: Zhibo Hu < <mailto:[email-masked]> [email-masked]>; Gyan Mishra

        >>> < <mailto:[email-masked]> [email-masked]>; Aijun Wang < <mailto:[email-masked]> [email-masked]>;

        >>> Gyan S. Mishra < <mailto:[email-masked]> [email-masked]>

        >>> Subject: New Version Notification for

        >>> draft-wang-lsr-passive-interface-attribute-04.txt

        >>> A new version of I-D,

        >>> draft-wang-lsr-passive-interface-attribute-04.txt

        >>> has been successfully submitted by Aijun Wang and posted to the IETF

        >>> repository.

        >>> Name:               draft-wang-lsr-passive-interface-attribute

        >>> Revision:   04

        >>> Title:         Passive Interface Attribute

        >>> Document date:       2020-09-28

        >>> Group:               Individual Submission

        >>> Pages:               7

        >>> URL:

        >>>  <https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04.

        >>> txt

        >>> Status:

        >>>  <https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att

        >>> r

        >>> ibute/

        >>> Htmlized:

        >>>  <https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac

        >>> e

        >>> -attribut

        >>> e

        >>> Htmlized:

        >>>  <https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut

        >>> e

        >>> -04

        >>> Diff:

        >>>  <https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at

        >>> t

        >>> ribute-04

        >>> Abstract:

        >>>      This document describes the mechanism that can be used to

        >>>      differentiate the passive interfaces from the normal interfaces

        >>>      within ISIS or OSPF domain.

        >>> Please note that it may take a couple of minutes from the time of

        >>> submission until the htmlized version and diff are available at

        > tools.ietf.org.

        >>> The IETF Secretariat

        > _______________________________________________

        > Lsr mailing list

        >  <mailto:[email-masked]> [email-masked]

        >  <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

        _______________________________________________

        Lsr mailing list

         <mailto:[email-masked]> [email-masked]

         <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

    _______________________________________________

    Lsr mailing list

     <mailto:[email-masked]> [email-masked]

     <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________

Lsr mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 9 Oct 2020 19:48:03 +0000

Speaking as WG member:

Hi Aijun,

From: Aijun Wang <[email-masked]>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, 'Aijun Wang' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:

Please see inline.[WAJ]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; 'Aijun Wang' <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

Right – and nobody other than yourself believes the IGPs should be modified to expose the abstracted topology of an area outside that area. You can solve the problem with BGP-LS session(s) between the router with a BGP-LS session to the controller and a router in each area w/o  a router with a BGP-LS session to the controller.

It really isn’t relevant, but I have to ask…. How does the presence of a prefix associated with a passive interface allow you to make this deduction?

Thanks,

Acee

Thanks,

Acee

On 9/29/20, 10:39 PM, "Aijun Wang" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi, Acee and Peter:

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)

    To: Peter Psenak <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Aijun Wang' <[email-masked]<mailto:[email-masked]>>

    Cc: [email-masked]<mailto:[email-masked]>

    Speaking as WG member:

    Hi Aijun, Peter,

    Thanks,

    Acee

    On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]<mailto:[email-masked]%20on%20behalf%20of%20ppsenak=[email-masked]>> wrote:

        Hi Aijun,

        ends, but

        thanks,

        Peter

        > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Peter

        > To: Aijun Wang <[email-masked]<mailto:[email-masked]>>

        > Cc: [email-masked]<mailto:[email-masked]>

        >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface

        >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

        >>> To: Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Gyan Mishra

        >>> <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>;

        >>> Gyan S. Mishra <[email-masked]<mailto:[email-masked]>>

        >>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04.

        >>> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att

        >>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac

        >>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut

        >>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at

        > [email-masked]<mailto:[email-masked]>

        > https://www.ietf.org/mailman/listinfo/lsr

        Lsr mailing list

        [email-masked]<mailto:[email-masked]>

        https://www.ietf.org/mailman/listinfo/lsr

    Lsr mailing list

    [email-masked]<mailto:[email-masked]>

    https://www.ietf.org/mailman/listinfo/lsr

Lsr mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 10 Oct 2020 09:58:16 +0800

Hi, Acee:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 AM
To: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; 'Aijun Wang' <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun, 

From: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, "Peter Psenak (ppsenak)" <[email-masked] <mailto:[email-masked]> >, 'Aijun Wang' <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:

Please see inline.[WAJ]

-----Original Message-----                                                                                                                                              
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >; 'Aijun Wang' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun, 

Right – and nobody other than yourself believes the IGPs should be modified to expose the abstracted topology of an area outside that area. 

[WAJ]  The modification doesn’t change the way and complexity of route calculation within IGP. It just piggyback some extra information, the bulk of the reconstruction work is done by the controller.  Such extra information can also have other usage, as described in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#section-1

And, the proposal described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-04 is different with the problem you concerned.  It has no relation with the abstracted topology of an area.  Maybe you are confused by these two drafts?

You can solve the problem with BGP-LS session(s) between the router with a BGP-LS session to the controller and a router in each area w/o  a router with a BGP-LS session to the controller. 

[WAJ] This is possible, but not efficient. For operation, we must also consider the configuration/administration overhead.  BGP-LS is designed mainly for the northbound protocol, not east-west protocol.

[WAJ] Passive interfaces are deployed mainly at the boundary of IGP domain.  Is there any other exception?

Thanks,

Acee

Thanks,

Acee

    Hi, Acee and Peter:

 

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    Speaking as WG member:

    Hi Aijun, Peter, 

    Thanks,

    Acee

        Hi Aijun,

        ends, but

        thanks,

        Peter

        Lsr mailing list

    Lsr mailing list

 

Lsr mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 10 Oct 2020 10:29:23 +0000

Hi Aijun,

Date: Friday, October 9, 2020 at 9:58 PM

Hi, Acee:

Speaking as WG member:

Hi Aijun,

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>, 'Aijun Wang' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:

Please see inline.[WAJ]

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; 'Aijun Wang' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

It is a similar problem. You are still trying to overload the prefix advertisements with a link attribute (passive interface) so that it can be conveyed outside the domain. We certainly wouldn’t waste a limited prefix flag on this parochial application.

While passive interfaces are not standardized, there is nothing that limits their usage to an IGP boundary. They can and are deployed on any interface where adjacencies are not to be formed (e.g., a stub subnet containing hosts).

Thanks,
Acee

Thanks,

Acee

Thanks,

Acee

    Hi, Acee and Peter:

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    Speaking as WG member:

    Hi Aijun, Peter,

    Thanks,

    Acee

        Hi Aijun,

        ends, but

        thanks,

        Peter

        Lsr mailing list

    Lsr mailing list

Lsr mailing list

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 11 Oct 2020 15:19:14 -0400

Hi Acee

I believe what Aijun is trying to explain is that the primary purpose of
PCE for active or passive path computation is for inter-as RSVP-TE PCALC
path computation or SR-TE path computation.  So PCE is solving a well known
PCALC bin packing problem due to pcalc over subscribing RSVP tunnel
bandwidth which is inherent an RSVP issue, but a bigger problematic issue
is with being able to build an inter-as TE path with a single or multiple
PCE controllers that can take the LSDB link attributes in the TEDs dB
opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topology
topology from each TE domain to be able to build a congruent end to end
RSVP TE or SR-TE traffic steered path instantiation.

Without the use of PCE controllers as the LSDB link attribute information
is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid
loose path is built, failover due to crank back is impacted for reroute,
due to not having a complete depiction of the other AS Link state topology
by the head end or SR source node.

So to build that entire end to end inter-as path for that end to end RSVP
TE or SR-TE path instantiation it is critical to indentify the inter-as
link eBGP tie link that may have static routes or BGP LU for RSVP head end
to tail end reachability and SR-TE reachability to build out the end to end
path instantiation.  So the BGP-LS task to  rebuild the lsdb topology of
each inter connected AS that the RSVP TE or SR-TE steered path traverses,
we need the accurate depiction and that includes the Identification of the
 critical inter-as tie link eBGP peering link that is passive for the PCE
path computation logic for the end to end inter-as path instantiation.

As for other interfaces using passive in the context of a operator service
provider or enterprise core P and PE routers all links are transit with
neighbors except the inter-as tie so having this new IGP TLV will help to
that end.  In the operator “core” network if there are other  interfaces
that don’t need to be advertised as stub, they can easily be excluded from
being added into IGP.

Kind Regards

Gyan

On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Hi Aijun,
>
>
>
> *From: *Aijun Wang <[email-masked]>
> *Date: *Friday, October 9, 2020 at 9:58 PM
> *To: *Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" <
> [email-masked]>, 'Aijun Wang' <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [Lsr] FW: New Version Notification for
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Saturday, October 10, 2020 3:48 AM
> *To:* Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; 'Aijun Wang' <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] FW: New Version Notification for
> *From: *Aijun Wang <[email-masked]>
> *Date: *Thursday, October 8, 2020 at 11:09 PM
> *To: *Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" <
> [email-masked]>, 'Aijun Wang' <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [Lsr] FW: New Version Notification for
> From: [email-masked] [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Acee Lindem (acee)
> To: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; 'Aijun Wang' <[email-masked]>
> Cc: [email-masked]
> [WAJ] The topology discovery heuristic is not suitable for the corner use
> case when the unnumbered interface is used, as explained in
> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B.
> If you don’t agree, would you like to illustrate other non-applicable
> scenarios?
>
>
>
> Right – and nobody other than yourself believes the IGPs should be
> modified to expose the abstracted topology of an area outside that area.
>
> *[WAJ]  The modification doesn’t change the way and complexity of route
> calculation within IGP. It just piggyback some extra information, the bulk
> of the reconstruction work is done by the controller.  Such extra
> information can also have other usage, as described in
> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#section-1
> <https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#section-1>*
>
> *And, the proposal described in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-04
> <https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-04>
> is different with the problem you concerned.  It has no relation with the
> abstracted topology of an area.  Maybe you are confused by these two
> drafts?*
>
>
>
> It is a similar problem. You are still trying to overload the prefix
> advertisements with a link attribute (passive interface) so that it can be
> conveyed outside the domain. We certainly wouldn’t waste a limited prefix
> flag on this parochial application.
>
>
>
>
>
> You can solve the problem with BGP-LS session(s) between the router with a
> BGP-LS session to the controller and a router in each area w/o  a router
> with a BGP-LS session to the controller.
>
> *[WAJ] This is possible, but not efficient. For operation, we must also
> consider the configuration/administration overhead.  BGP-LS is designed
> mainly for the northbound protocol, not east-west protocol.*
>
>
>
> [WAJ] To know the boundary of the IGP domain. After knowing the boundary,
> the controller can safely apply and check the network security policy, the
> inbound traffic control policy etc.
>
>
>
> It really isn’t relevant, but I have to ask…. How does the presence of a
> prefix associated with a passive interface allow you to make this
> deduction?
>
> *[WAJ] Passive interfaces are deployed mainly at the boundary of IGP
> domain.  Is there any other exception?*
>
> While passive interfaces are not standardized, there is nothing that
> limits their usage to an IGP boundary. They can and are deployed on any
> interface where adjacencies are not to be formed (e.g., a stub subnet
> containing hosts).
>
>
>
> Thanks,
> Acee
>
>
>
> Thanks,
>
> Acee
>
>
>
> Thanks,
>
> Acee
>
>
>
> On 9/29/20, 10:39 PM, "Aijun Wang" <[email-masked]> wrote:
>
>
>
>     Hi, Acee and Peter:
>
>     And the information to flag the passive interfaces is for positioning
> the area boundary, not conflict with the abstract capabilities of the area
> inside.
>
>
>
>
>
>     Best Regards
>
>
>
>     Aijun Wang
>
>     China Telecom
>
>
>
>     From: [email-masked] [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Acee Lindem (acee)
>
>     To: Peter Psenak <ppsenak=[email-masked]>; Aijun Wang <
> [email-masked]>; 'Aijun Wang' <[email-masked]>
>
>     Cc: [email-masked]
>
>     I agree with Peter - one of the main motivations for having areas is
> to abstract the topology within the area. Now you're trying to supplant
> this  - one topological detail at a time with ill-conceived IGP features.
>
>     Thanks,
>
>     Acee
>
>
>
>     On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" <[email-masked]
> on behalf of ppsenak=[email-masked]
> <[email-masked]%20on%20behalf%20of%20ppsenak=[email-masked]>>
> wrote:
>
>
>
>         Hi Aijun,
>
>
>
>         > protocol. This is main reason to extension the IGP protocol. >
> 2. For the solution, normally, the link within the IGP connect two
>
>         ends, but
>
>         > From: [email-masked] [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Peter
>
>         > Psenak
>
>         > To: Aijun Wang <[email-masked]>
>
>         > Cc: [email-masked]
>
>         >>> From: [email-masked] [
> mailto:[email-masked] <[email-masked]>]
>
>         >>> To: Zhibo Hu <[email-masked]>; Gyan Mishra
>
>         >>> <[email-masked]>; Aijun Wang <
> [email-masked]>;
>
>         >>> Gyan S. Mishra <[email-masked]>
>
>         > [email-masked]
>         [email-masked]
>     [email-masked]
> [email-masked]
> [email-masked]
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 12 Oct 2020 11:27:42 +0800

Hi, Acee:

As Gyan’s explain, the information that identifies the passive interfaces will give the operators the capabilities to accomplish TE task across the different AS domains.

And, flooding such passive/boundary information within IGP can lead to the flexibility of  BGP-LS deployment-----any router within the IGP domain can report such information to PCE.

More replies are inline below.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Monday, October 12, 2020 3:19 AM
To: Acee Lindem (acee) <acee=[email-masked]>
Cc: [email-masked]; Aijun Wang <[email-masked]>; Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Acee

I believe what Aijun is trying to explain is that the primary purpose of PCE for active or passive path computation is for inter-as RSVP-TE PCALC path computation or SR-TE path computation.  So PCE is solving a well known PCALC bin packing problem due to pcalc over subscribing RSVP tunnel bandwidth which is inherent an RSVP issue, but a bigger problematic issue is with being able to build an inter-as TE path with a single or multiple PCE controllers that can take the LSDB link attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topology topology from each TE domain to be able to build a congruent end to end RSVP TE or SR-TE traffic steered path instantiation.

Without the use of PCE controllers as the LSDB link attribute information is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid loose path is built, failover due to crank back is impacted for reroute, due to not having a complete depiction of the other AS Link state topology by the head end or SR source node.

So to build that entire end to end inter-as path for that end to end RSVP TE or SR-TE path instantiation it is critical to indentify the inter-as link eBGP tie link that may have static routes or BGP LU for RSVP head end to tail end reachability and SR-TE reachability to build out the end to end path instantiation.  So the BGP-LS task to  rebuild the lsdb topology of each inter connected AS that the RSVP TE or SR-TE steered path traverses, we need the accurate depiction and that includes the Identification of the  critical inter-as tie link eBGP peering link that is passive for the PCE path computation logic for the end to end inter-as path instantiation.  

As for other interfaces using passive in the context of a operator service provider or enterprise core P and PE routers all links are transit with neighbors except the inter-as tie so having this new IGP TLV will help to that end.  In the operator “core” network if there are other  interfaces that don’t need to be advertised as stub, they can easily be excluded from being added into IGP.  

Kind Regards 

Gyan

On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]> > wrote:

Hi Aijun, 

Hi, Acee:

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Acee Lindem (acee)

Speaking as WG member:

Hi Aijun, 

Hi, Acee:

Please see inline.[WAJ]

Hi Aijun, 

[WAJ] Such information is flooded within the domain, not outside the domain. One bit flag can facilitate the calculation of inter-as path. Is there any other exist flags has such important usages?

[WAJ] Isn’t the interface that connects “a stub subnet containing hosts” IGP boundary?

Thanks,
Acee

Thanks,

Acee

Thanks,

Acee

    Hi, Acee and Peter:

 

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    Speaking as WG member:

    Hi Aijun, Peter, 

    Thanks,

    Acee

        Hi Aijun,

        ends, but

        thanks,

        Peter

        > tools.ietf.org <http://tools.ietf.org> .

        Lsr mailing list

    Lsr mailing list

 

Lsr mailing list

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

-- 

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 12 Oct 2020 12:55:10 +0530

Hi Gyan,

As far as PCE is concerned, we have the inter-AS link information via
RFC 5316 and RFC 5392. Both of these include a section on PCE's BRPC
procedure for instance.

I see you have other use cases, but it would be good to highlight why
for the PCE use case the above is deficient.

Thanks!
Dhruv

On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra <[email-masked]> wrote:
> On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) <acee=[email-masked]> wrote:
>>
>> Hi Aijun,
>>
>>
>>
>>     To: Peter Psenak <ppsenak=[email-masked]>; Aijun Wang <[email-masked]>; 'Aijun Wang' <[email-masked]>
>>
>>     Cc: [email-masked]
>>
>>     On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:
>>
>>
>>
>>         Hi Aijun,
>>
>>
>>
>>         > From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
>>
>>         > Psenak
>>
>>         >>> From: [email-masked] [mailto:[email-masked]]
>>
>>         >>> <[email-masked]>; Aijun Wang <[email-masked]>;
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 12 Oct 2020 18:05:56 +0000

Speaking WG member:

Hi Gyan, Aijun,

Even if I agreed with your use case assuming a passive interface denotes the boundary between two domains as shown in figure 1 in your draft (which I don’t), you still should not be trying to hack the prefixes with what is inherently link attribute. Can I state this anymore simply or are you are just going to restate your requirements again???

Acee

From: Gyan Mishra <[email-masked]>
Date: Sunday, October 11, 2020 at 3:19 PM
To: Acee Lindem <[email-masked]>
Cc: Aijun Wang <[email-masked]>, Aijun Wang <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Acee

Kind Regards

Gyan

On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
Hi Aijun,

Hi, Acee:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Acee Lindem (acee)

Speaking as WG member:

Hi Aijun,

Hi, Acee:

Please see inline.[WAJ]

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; 'Aijun Wang' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

Thanks,
Acee

Thanks,

Acee

Thanks,

Acee

    Hi, Acee and Peter:

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    Speaking as WG member:

    Hi Aijun, Peter,

    Thanks,

    Acee

        Hi Aijun,

        ends, but

        thanks,

        Peter

        > tools.ietf.org<http://tools.ietf.org>.

        Lsr mailing list

    Lsr mailing list

Lsr mailing list

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 12 Oct 2020 14:22:26 -0700

I’m with Acee here, the presence of a passive interface in a topology is in no way unambiguously signaling domain boundaries. You could “hack around” though, but that would defeat the purpose of an IETF document.
Keeping it to OSPFv2 (other protocols have similar ways of doing that), I’d say, using a technique similar to that, defined for Inter-AS-TE-v2 LSA provides you exactly that.

Cheers,
Jeff
On Oct 12, 2020, 11:06 AM -0700, Acee Lindem (acee) <acee=[email-masked]>, wrote:
> > quote_type
> >         > Hi, Peter:
> >         >
> >         > Thanks for your comments.
> >         > 1. For BGP-LS deployment, there normally only be one router that within the
> >         > IGP domain to report the topology information, this router should know such
> >         > passive links which exists mainly on other border routers via the IGP
> >         > protocol. This is main reason to extension the IGP protocol. > 2. For the solution, normally, the link within the IGP connect two
> >         ends, but
> >         > passive interface is special and not fall in this space. We have studied the
> >         > current TLVs that for link, and find no suitable container to append this
> >         > information. This is the reason that we select the TLVs that associated with
> >         > Prefix.
> >
> >         >
> >         >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix LSA", which
> >         > isolate the prefix information that associated with link into this
> >         > container, contains the stub link, local interface information etc. Put such
> >         > attribute along with the prefix is then acceptable?
> >         >
> >         >
> >         > Best Regards
> >         >
> >         > Aijun Wang
> >         > China Telecom
> >         >
> >         > -----Original Message-----
> >         > From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
> >         > Psenak
> >         > Sent: Tuesday, September 29, 2020 4:29 PM
> >         > To: Aijun Wang <[email-masked]>
> >         > Cc: [email-masked]
> >         > Subject: Re: [Lsr] FW: New Version Notification for
> >         > draft-wang-lsr-passive-interface-attribute-04.txt
> >         >
> >         > Hi Aijun,
> >         >
> >         > here's my comments:
> >         >
> >         > The purpose of this draft is to advertise passive links.
> >         >
> >         > 1. I'm not sure the problem needs to be solved by IGPs. I tend to believe
> >         > ietf-idr-bgpls-inter-as-topology-ext is sufficient.
> >         >
> >         > 2. the solution that you proposed is wrong. You are trying to derive
> >         > topological data about the passive links from the prefix advertisement.
> >         > This is semantically incorrect and only works under very specific condition.
> >         > If you need to advertise a link, advertise it as a "special"
> >         > link, not as a "special" prefix.
> >         >
> >         > thanks,
> >         > Peter
> >         >
> >         > On 29/09/2020 03:17, Aijun Wang wrote:
> >         >> Hi, Peter:
> >         >>
> >         >> Would you like to review and give comments on the updates version of this
> >         > draft?
> >         >> We have also added the protocol extension proposal for OSPFv3.
> >         >>
> >         >> The update version of this draft can refer to
> >         >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface
> >         >> -attribute
> >         >> Thanks in advance.
> >         >>
> >         >>
> >         >> Best Regards
> >         >>
> >         >> Aijun Wang
> >         >> China Telecom
> >         >>
> >         >>> -----Original Message-----
> >         >>> From: [email-masked] [mailto:[email-masked]]
> >         >>> Sent: Monday, September 28, 2020 3:17 PM
> >         >>> To: Zhibo Hu <[email-masked]>; Gyan Mishra
> >         >>> <[email-masked]>; Aijun Wang <[email-masked]>;
> >         >>> Gyan S. Mishra <[email-masked]>
> >         >>> Subject: New Version Notification for
> >         >>> draft-wang-lsr-passive-interface-attribute-04.txt
> >         >>>
> >         >>>
> >         >>> A new version of I-D,
> >         >>> draft-wang-lsr-passive-interface-attribute-04.txt
> >         >>> has been successfully submitted by Aijun Wang and posted to the IETF
> >         >>> repository.
> >         >>>
> >         >>> Name:               draft-wang-lsr-passive-interface-attribute
> >         >>> Revision:   04
> >         >>> Title:         Passive Interface Attribute
> >         >>> Document date:       2020-09-28
> >         >>> Group:               Individual Submission
> >         >>> Pages:               7
> >         >>> URL:
> >         >>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04.
> >         >>> txt
> >         >>> Status:
> >         >>> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att
> >         >>> r
> >         >>> ibute/
> >         >>> Htmlized:
> >         >>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac
> >         >>> e
> >         >>> -attribut
> >         >>> e
> >         >>> Htmlized:
> >         >>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut
> >         >>> e
> >         >>> -04
> >         >>> Diff:
> >         >>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at
> >         >>> t
> >         >>> ribute-04
> >         >>>
> >         >>> Abstract:
> >         >>>      This document describes the mechanism that can be used to
> >         >>>      differentiate the passive interfaces from the normal interfaces
> >         >>>      within ISIS or OSPF domain.
> >         >>>
> >         >>>
> >         >>>
> >         >>>
> >         >>> Please note that it may take a couple of minutes from the time of
> >         >>> submission until the htmlized version and diff are available at
> >         > tools.ietf.org.
> >         >>>
> >         >>> The IETF Secretariat
> >         >>>
> >         >>
> >         >>
> >         >>
> >         >>
> >         >
> >         > _______________________________________________
> >         > Lsr mailing list
> >         > [email-masked]
> >         > https://www.ietf.org/mailman/listinfo/lsr
> >         >
> >         >
> >         >
> >
> <>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Oct 2020 10:24:39 +0800

Hi, Jeff:

Using the solution that similar with Inter-AS-TE-v2 LSA(https://tools.ietf.org/html/rfc5392#section-3.1.1) is straightforward but has the following constraints:

1.     It requires the configuration of the remote-as/remote ASBR ID on border router, and requires the advertisement of the redundant information on every Link TLV that included in such LSA.

2.     It requires the configuration of the remote interface address on every inter-as link, which is tedious work.

3.     It requires the proxy of remote neighbor information on every inter-as link, as that described in https://tools.ietf.org/html/rfc5392#section-4.1

Such solution is obvious not as concise as deducting the IGP domain boundary from the passive interface attribute and interconnect them by the PCE. 

And the PCE doesn’t depend solely on such information to reconstruct the boundary, it has some algorithm to exclude the extraordinary scenario【for example, when the prefix length is 32(IPv4) or 128(IPv6)bit length】 

The ASBR just needs to flag the prefix is coming from the passive interface, nothing more. Such flag mechanism is not defeat the purpose of IETF document.

And Acee:

Please see inline for your concerns.

Best Regards

Aijun Wang

China Telecom

From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Tuesday, October 13, 2020 5:22 AM
To: Gyan Mishra <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Cc: [email-masked]; Aijun Wang <[email-masked]>; Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Cheers, 

Jeff

On Oct 12, 2020, 11:06 AM -0700, Acee Lindem (acee) <acee=[email-masked] <mailto:acee=[email-masked]> >, wrote:

Speaking WG member:

Hi Gyan, Aijun,

Even if I agreed with your use case assuming a passive interface denotes the boundary between two domains as shown in figure 1 in your draft (which I don’t), you still should not be trying to hack the prefixes with what is inherently link attribute.

[WAJ] There is no space now within the IGP protocol to describe the stub/passive link attribute. When we talk link, we often refer to the link that connects two IGP neighbors.

And, using the prefix passive flag to position the IGP boundary, is the reasonable deduction, not hack. 

 Can I state this anymore simply or are you are just going to restate your requirements again???

[WAJ] Just want to emphasize the potential usage of such information, and be clear also for other experts.

Acee

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Date: Sunday, October 11, 2020 at 3:19 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, Aijun Wang <[email-masked] <mailto:[email-masked]> >, "Peter Psenak (ppsenak)" <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Acee

Kind Regards 

Gyan

Hi Aijun,

Hi, Acee:

Speaking as WG member:

Hi Aijun,

Hi, Acee:

Please see inline.[WAJ]

Hi Aijun,

 

Thanks,
Acee

Thanks,

Acee

Thanks,

Acee

    Hi, Acee and Peter:

 

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    Speaking as WG member:

    Hi Aijun, Peter,

    Thanks,

    Acee

        Hi Aijun,

        ends, but

        thanks,

        Peter

        Lsr mailing list

    Lsr mailing list

 

Lsr mailing list

--

 <http://www.verizon.com/> <>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Oct 2020 10:33:33 +0800

Hi, Dhruv:

Please see my explain to Jeff. https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/

The solutions described in RFC 5316 and RFC 5392 are possible and straightforward, but they have some constraints, especially for the operation/configuration of the network.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 12, 2020 3:25 PM
To: Gyan Mishra <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; Aijun Wang <[email-masked]>; Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Gyan,

As far as PCE is concerned, we have the inter-AS link information via RFC 5316 and RFC 5392. Both of these include a section on PCE's BRPC procedure for instance.

I see you have other use cases, but it would be good to highlight why for the PCE use case the above is deficient.

Thanks!
Dhruv

On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra <[email-masked]> wrote:
>> To: Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" 
>> <[email-masked]>, 'Aijun Wang' <[email-masked]>
>> Subject: RE: [Lsr] FW: New Version Notification for 
>> To: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) 
>> <[email-masked]>; 'Aijun Wang' <[email-masked]>
>> Cc: [email-masked]
>> To: Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" 
>> <[email-masked]>, 'Aijun Wang' <[email-masked]>
>> Subject: RE: [Lsr] FW: New Version Notification for 
>> To: Aijun Wang <[email-masked]>; Peter Psenak (ppsenak) 
>> <[email-masked]>; 'Aijun Wang' <[email-masked]>
>> Cc: [email-masked]
>> [WAJ]  The modification doesn’t change the way and complexity of 
>> route calculation within IGP. It just piggyback some extra 
>> information, the bulk of the reconstruction work is done by the 
>> controller.  Such extra information can also have other usage, as 
>> described in 
>>     To: Peter Psenak <ppsenak=[email-masked]>; Aijun Wang 
>> <[email-masked]>; 'Aijun Wang' <[email-masked]>
>>
>>     Cc: [email-masked]
>>
>>         > protocol. This is main reason to extension the IGP 
>> protocol. > 2. For the solution, normally, the link within the IGP 
>> connect two
>>
>>         ends, but
>>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 13 Oct 2020 11:17:42 +0530

Hi Aijun,

I am not particularly sold on the argument that the configuration
requirements of RFC 5316/RFC 5392 are especially burdensome.

A PCE relies on the TEDB which comprises nodes & links, and it makes
sense to have an inter-AS link represented as a "Link". Moreover,
these links are TE-enabled and thus carry the TE properties of the
link. You cannot avoid using this mechanism if Inter-AS Link's
TE-properties need to be advertised.

That is why I consider your proposal to be more applicable for non-TE
use cases perhaps(?)!

Thanks!
Dhruv

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Oct 2020 16:05:05 +0800

Hi, Dhruv:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Tuesday, October 13, 2020 1:48 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; Peter Psenak (ppsenak) <[email-masked]>; Aijun Wang <[email-masked]>; Gyan Mishra <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

I am not particularly sold on the argument that the configuration requirements of RFC 5316/RFC 5392 are especially burdensome.

A PCE relies on the TEDB which comprises nodes & links, and it makes sense to have an inter-AS link represented as a "Link". Moreover, these links are TE-enabled and thus carry the TE properties of the link. You cannot avoid using this mechanism if Inter-AS Link's TE-properties need to be advertised.
[WAJ] Yes. For deploying the inter-as TE based on RFC5316/RFC539, we must configure the properties parameters on every inter-AS link manually. Interface address/Remote Router ID/Remote AS are just part of these configuration. 

That is why I consider your proposal to be more applicable for non-TE use cases perhaps(?)!
[WAJ] To be exact, the proposal is more applicable for non-MPLS TE use case. But it can also relieve the configuration overhead for MPLS TE use case.

Thanks!
Dhruv

On Tue, Oct 13, 2020 at 8:03 AM Aijun Wang <[email-masked]> wrote:
>
> Hi, Dhruv:
>
> Please see my explain to Jeff. 
> https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/
>
> Cc: Acee Lindem (acee) <acee=[email-masked]>; 
> [email-masked]; Aijun Wang <[email-masked]>; Aijun Wang 
> <[email-masked]>; Peter Psenak (ppsenak) 
> <[email-masked]>
> >> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-0
> >> 6#
> >> section-1
> >>
> >>     To: Peter Psenak <ppsenak=[email-masked]>; Aijun 
> >> Wang <[email-masked]>; 'Aijun Wang' 
> >> <[email-masked]>
> >>
> >>     Cc: [email-masked]
> >>