From: netmod <[email protected]> on behalf of Qin Wu <[email protected]> Sent: 31 July 2020 11:40
-----邮件原件----- 发件人: Acee Lindem (acee) [mailto:[email protected]] 发送时间: 2020年7月31日 18:22 Hi Qin, On 7/30/20, 9:23 PM, "Qin Wu" <[email protected]> wrote: -----邮件原件----- 发件人: netmod [mailto:[email protected]] 代表 Acee Lindem (acee) 发送时间: 2020年7月31日 5:06 Hi Kent, On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" <[email protected] on behalf of [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
