Subject: Re: [netmod] rfc6991bis: loopback addresses

From: Qin Wu <[email-masked]>
Date: Fri, 31 Jul 2020 10:40:20 +0000

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:[email-masked]] 
发送时间: 2020年7月31日 18:22
收件人: Qin Wu <[email-masked]>; Kent Watsen <[email-masked]>; Juergen Schoenwaelder <[email-masked]>
抄送: Carlos Pignataro (cpignata) <[email-masked]>; [email-masked]
主题: Re: [netmod] rfc6991bis: loopback addresses

Hi Qin, 

On 7/30/20, 9:23 PM, "Qin Wu" <[email-masked]> wrote:

    -----邮件原件-----
    发件人: netmod [mailto:[email-masked]] 代表 Acee Lindem (acee)
    发送时间: 2020年7月31日 5:06
    收件人: Kent Watsen <[email-masked]>; Juergen Schoenwaelder <[email-masked]>
    抄送: Carlos Pignataro (cpignata) <[email-masked]>; [email-masked]
    主题: Re: [netmod] rfc6991bis: loopback addresses

    Hi Kent,

    On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" <[email-masked] on behalf of [email-masked]> wrote:

        > Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
        > With that, your request is relatively clear now

        Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” that constrains inet:ipv[46]-address so that it can only contain loopback address values.

        > and the question the WG
        > needs to answer is whether these types are common enough to warrant being
        > part of inet-types, i.e., are there any other places where these types
        > may be useful?

        I don’t think so, but I’m not a routing person.

    I wouldn't think that an internal loopback address would be widely used. In fact, I checked our Cisco native models for IOS-XE and there is no such definition. 

    [Qin]: I am not sure we are talking about loopback type or loopback address
    See section 2.4 in draft-ietf-netmod-intf-ext-yang-10, 3 type loopbacks are defined:
    1.Internal loopback
    2.Line loopback
    3.Loopback Connector
    3 types loopback can be classified into local loopback and remote loopback.
    I am not sure they are common, but we have some support for this. 

This is the loopback address type - not the loopback interface type. Look at draft-nainar-mpls-lsp-ping-yang (the draft being discussed in the Email thread). 

[Qin]:I understand, but I feel related. Maybe I am wrong.
Thanks,
Acee

    Thanks,
    Acee

        > /js

        K.  // contributor
        _______________________________________________
        netmod mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/netmod

    _______________________________________________
    netmod mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netmod

---

From: tom petch <[email-masked]>
Date: Fri, 31 Jul 2020 11:01:21 +0000

From: netmod <[email-masked]> on behalf of Qin Wu <[email-masked]>
Sent: 31 July 2020 11:40

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:[email-masked]]
发送时间: 2020年7月31日 18:22

Hi Qin,

    -----邮件原件-----
    发件人: netmod [mailto:[email-masked]] 代表 Acee Lindem (acee)
    发送时间: 2020年7月31日 5:06

    Hi Kent,

<tp>
we SHOULD NOT add this type.  Just look at the confusion that this is causing.

I learnt loopback as something you did to hardware to loop the traffic back for testing.  I think it unfortunate that 127/8 was defined as loopback when a major router manufacturer, only one that I knew of, used loopback as an alternative to Ethernet as an interface type that was always up and so could provide a permanently available IP address for communications with a router; the address cannot be 127/8 as that is unroutable.   This use of an interface type then gets used as a  router I-D which of course is a 32 bit number with  no properties, something that YANG models have been getting right.
MPLS exploited the properties of 127/8 for diagnostics and since 127/8 is loopback then MPLS makes extensive use of loopback.
Meanwhile every other WG uses loopback in the sense an interface type that is always up; there are dozens of RFC and I-D in that category.  I think it wrong for YANG to endorse this use.  
I also think that since the 127/8 meaning is now limited to MPLS, RFC1122  and some IPv6 documentation AFAICT, then defining a YANG type for 127/8 as loopback will cause chaos.
So MPLS needs a type, let draft-nainar define it but it MUST NOT be called loopback and it MUST NOT appear in 6991bis since it is MPLS only..

HTH

Tom Petch

Thanks,
Acee

    Thanks,
    Acee

        K.  // contributor