Re: [netmod] rfc6991bis: loopback addresses

[tom petch <[e-mail]>]

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

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

Hi Qin,

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

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

    Hi Kent,

    On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" <[e-mail] on behalf of [e-mail]> 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.

<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


        > /js

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

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

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