Re: [OSPF] 答复: [Isis-wg] 答复: 答复: [sunset4] IPv6 router IDs

[Xuxiaohu <[e-mail]>]

Hi Acee,

The old draft (http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) has been replaced by the new draft (http://tools.ietf.org/html/draft-xu-ospf-routable-ip-address-00). In the latter draft, two precise use cases have been included (see section 1). I wonder whether the latter draft has addressed your concerns.

Best regards,
Xiaohu

> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]]
> Sent: Monday, May 12, 2014 9:40 PM
> To: Xuxiaohu
> Cc: Karsten Thomann; Anton Smirnov; [e-mail];
> [e-mail]; Wes George; Joel jaeggli; OSPF List;
> [e-mail]; [e-mail]
> Subject: Re: 答复: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
> 
> Hi Xiaohu,
> Please include the precise use cases as to WHY this is needed OSPF draft.
> And by precise, I don't mean just listing MPLS applications, I mean explaining
> why you need this routable address above and beyond what is already
> advertised. At least in the case of OSPF, I'm not convinced.
> Thanks,
> Acee
> 
> 
> -----Original Message-----
> From: Xuxiaohu <[e-mail]>
> Date: Sunday, May 11, 2014 6:44 PM
> To: Ericsson <[e-mail]>
> Cc: Karsten Thomann <[e-mail]>, Anton Smirnov
> <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, Wes George
> <[e-mail]>, Joel jaeggli <[e-mail]>, OSPF - OSPF
> WG List <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>
> Subject: 答复: [Isis-wg] [OSPF] 答复:  答复:  [sunset4]   IPv6 router IDs
> 
> >Hi Acee,
> >
> >IMHO, segment routing could work together with the RFC3464 VPN. In such
> >case, the segment routing just replace the role of LDP or RSVP-TE of
> >establishing a transport LSP between PE routers.
> >
> >Best regards,
> >Xiaohu
> >
> >> -----邮件原件-----
> >> 发件人: Acee Lindem [mailto:[e-mail]]
> >> 发送时间: 2014年5月9日 20:11
> >> 收件人: Xuxiaohu
> >> 抄送: Karsten Thomann; Anton Smirnov; [e-mail];
> >> [e-mail]; Wes George; Joel jaeggli; OSPF List;
> >> [e-mail]; [e-mail]
> >> 主题: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
> >>
> >> Xiaohu,
> >>
> >> The reason the use case is confusing is that the term L3VPN is commonly
> >>used to
> >> refer to RFC 4364 VPNs. In your use case, you are hypothesizing
> >>something for
> >> Segment Routed L3VPNs that I’m not sure is needed with MPLS. Can you
> add
> >> some real use cases to your drafts with justification that it is needed?
> >>
> >> Acee
> >> On May 9, 2014, at 5:31 AM, Xuxiaohu <[e-mail]> wrote:
> >>
> >> > Hi Karsten,
> >> >
> >> > Your understanding is completely correct.
> >> >
> >> > Best regards,
> >> > Xiaohu
> >> >
> >> >> -----邮件原件-----
> >> >> 发件人: Isis-wg [mailto:[e-mail]] 代表 Karsten
> Thomann
> >> >> 发送时间: 2014年5月9日 16:58
> >> >> 收件人: Xuxiaohu; Anton Smirnov
> >> >> 抄送: [e-mail]; George, Wes; [e-mail]; joel
> >> >> jaeggli; OSPF List; [e-mail]; [e-mail]
> >> >> 主题: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
> >> >>
> >> >> Hi Xiaohu,
> >> >>
> >> >> I think I've understand your problem now, but please don't call it a
> >> >> Router ID, the router ID must not be an IP address.
> >> >> To avoid any confusion about it please call it a router ip or router
> >> >> address within the TLV.
> >> >> Please correct me if I'm wrong, but if I understand your drafts right
> >> >> you're not requesting a real IPv6 Router ID instead of the
> >> >> (arbitrary) 32bit ID, but a simple TLV to carry the routable IPv6
> >> >> address of the router which advertises the capability.
> >> >>
> >> >> If I understand it right, we should maybe fix the text of the other
> >> >> rfc to refect that it is an routable IP address, instead of a
> >> >> (possible) arbitrary but unique Router ID.
> >> >>
> >> >> Kind regards
> >> >> Karsten
> >> >>
> >> >> Am 09.05.2014 02:53, schrieb Xuxiaohu:
> >> >>> Hi Anton,
> >> >>>
> >> >>> When ISIS capability TLVs are flooded across areas, routers in one
> >> >>> area may
> >> >> need to establish correlations between IP addresses and capabilities
> >> >> of routers in another area. For example, assume IS-IS router A in one
> >> >> area has established a L3VPN session with IS-IS router B in another
> >> >> area. When router A needs to send L3VPN traffic to router B via a
> >> >> MPLS-SR tunnel, router A wants to know whether router B (identified
> >> >> by an IP address) has the ELC
> >> >> (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before
> >> >> inserting an EL into the MPLS-SR packet. In such case, it needs to
> >> >> contain at least one routable IP address in the capability TLV which
> >> >> has been flooded across area boundaries. In the IPv4 network, the
> >> >> 4-octect router ID field could contain such routable IPv4 address.
> >> >> However, in the IPv6 network, there is no counterpart field to
> >>contain a
> >> routable IPv6 address.
> >> >>>
> >> >>> Best regards,
> >> >>> Xiaohu
> >> >>>
> >> >>>> -----邮件原件-----
> >> >>>> 发件人: Anton Smirnov [mailto:[e-mail]]
> >> >>>> 发送时间: 2014年5月8日 22:49
> >> >>>> 收件人: Xuxiaohu
> >> >>>> 抄送: [e-mail]; George, Wes; [e-mail]; joel
> >> >>>> jaeggli; OSPF List; [e-mail]; [e-mail]
> >> >>>> 主题: Re: [OSPF] 答复: 答复: [Isis-wg] [sunset4] IPv6 router IDs
> >> >>>>
> >> >>>>     Hello Xiaohu,
> >> >>>>     this whole thread started from George Wes stating that even in
> >> >>>> pure
> >> >>>> IPv4 world Router ID in many protocols is NOT an IPv4 address. For
> >> >>>> convenience it frequently is but on the binary scale "ID guaranteed
> >> >>>> to be routable IPv4 address"/"ID is just a number" - the Router ID
> >> >>>> is NOT an
> >> >> IPv4 address.
> >> >>>>
> >> >>>>     So, before you convince people that IPv6 Rtr ID is needed you
> >> >>>> must start from discussing when and why Router ID is being used as
> >> >>>> IPv4 address in pure
> >> >>>> IPv4 world. I believe this in other words is what Acee asking you.
> >> >>>>
> >> >>>> Anton
> >> >>>>
> >> >>>>
> >> >>>> On 05/07/2014 03:10 AM, Xuxiaohu wrote:
> >> >>>>> Hi Acee,
> >> >>>>>
> >> >>>>> The motivation for these two drafts
> >> >>>> (http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and
> >> >>>> http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very
> >> >>>> simple: the
> >> >>>> IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for advertising
> >> >>>> router capabilities can be flooded across areas, however, only a
> >> >>>> 4-octect router ID is carried in them. As a result, it’s hard for
> >> >>>> routers in one area to establish correlations between IPv6
> >> >>>> addresses and
> >> >> capabilities of routers in another area.
> >> >>>> For example, assume IS-IS router A in one area has established a
> >> >>>> L3VPN session with IS-IS router B in another area over their own
> >> >>>> IPv6 addresses. When router A needs to send L3VPN traffic to router
> >> >>>> B via a MPLS-SR tunnel, router A wants to know whether router B has
> >> >>>> the ELC
> >> >>>> (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before
> >> >>>> inserting an EL into the MPLS-SR packet . However, the Capability
> >> >>>> TLV originated by router B doesn’t carried an IPv6 address of its
> >> >>>> own. As a result,
> >> >> it !
> >> >>>>  s hard fo
> >> >>>> r router A to know the ELC of router B.
> >> >>>>> Best regards,
> >> >>>>> Xiaohu
> >> >>>>>
> >> >>>>>> -----邮件原件-----
> >> >>>>>> 发件人: Acee Lindem [mailto:[e-mail]]
> >> >>>>>> 发送时间: 2014年5月6日 21:14
> >> >>>>>> 收件人: Xuxiaohu
> >> >>>>>> 抄送: joel jaeggli; Acee Lindem; George, Wes; [e-mail];
> >> >>>>>> OSPF List; [e-mail]; [e-mail];
> >> >>>>>> [e-mail]
> >> >>>>>> 主题: Re: [OSPF] 答复: [Isis-wg] [sunset4] IPv6 router IDs
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On May 5, 2014, at 9:48 PM, Xuxiaohu <[e-mail]>
> >> wrote:
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>>> -----邮件原件-----
> >> >>>>>>>> 发件人: Isis-wg [mailto:[e-mail]] 代表 joel
> jaeggli
> >> >>>>>>>> 发送时间: 2014年5月5日 23:55
> >> >>>>>>>> 收件人: Acee Lindem; Xuxiaohu; George, Wes
> >> >>>>>>>> 抄送: [e-mail]; [e-mail];
> [e-mail];
> >> >>>>>>>> [e-mail]; [e-mail]
> >> >>>>>>>> 主题: Re: [Isis-wg] [sunset4] IPv6 router IDs
> >> >>>>>>>>
> >> >>>>>>>> On 5/5/14, 9:28 AM, Acee Lindem wrote:
> >> >>>>>>>>> Xiaohu – what are precisely the situations that you think you
> >> >>>>>>>>> need this
> >> >>>>>>>>> IPv6 address?
> >> >>>>>>>>> Acee
> >> >>>>>>>> if you're using router-id's as equivalency as an ipv4 unicast
> >>addresses.
> >> >>>>>>>> you're doing so at your peril because there is zero assurance
> >> >>>>>>>> that those actually map. the first time you have a router id of
> >> >>>>>>>> 11100000000000000000000000000101 well bummer.
> >> >>>>>>> The IPv6 router ID sub-TLV of the ISIS router capability TLV
> >> >>>>>>> must carry a
> >> >>>>>> "routable" IPv6 address. If the name of the sub-TLV seems
> >> >>>>>> confusing, it can be changed to IPv6 address sub-TLV.
> >> >>>>>>
> >> >>>>>> Independent of what you call it, you didn’t answer my question.
> >> >>>>>> Other than TE, what the use cases where it is needed?
> >> >>>>>>
> >> >>>>>> Acee
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> Best regards,
> >> >>>>>>> Xiaohu
> >> >>>>>>>
> >> >>>>>>>> I don't find the embedding of semantic meaning in router-ids to
> >> >>>>>>>> be more compelling then it was in ip addresses.
> >> >>>>>>>>
> >> >>>>>>>>> From: Xuxiaohu <[e-mail]
> >> >>>>>> <mailto:[e-mail]>>
> >> >>>>>>>>> Date: Sunday, May 4, 2014 1:29 AM
> >> >>>>>>>>> To: "George, Wes" <[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>>
> >> >>>>>>>>> Cc: OSPF - OSPF WG List <[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>" <[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>"
> <[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>" <[e-mail]
> >> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
> >> >>>>>>>> <mailto:[e-mail]>"
> >> >>>>>>>>> <[e-mail]
> >> >>>> <mailto:[e-mail]>>
> >> >>>>>>>>> Subject: Re: [Isis-wg] [sunset4] IPv6 router IDs
> >> >>>>>>>>>
> >> >>>>>>>>>     Hi Wes,
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     Thanks for pointing out these two drafts.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     The motivation for these two drafts
> >> >>>>>>>>>
> >>(http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and
> >> >>>>>>>>>
> >> >>>>>>>>> http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is
> >> >> very
> >> >>>>>>>>>     simple: the IPv6 ISIS|OSPF capability TLV/RI-LSA which are
> >> >>>>>>>>> used
> >> >> for
> >> >>>>>>>>>     advertising router capabilities can be flooded across
> >>areas,
> >> >>>>>>>>>     however, only a 4-octect router ID is carried in them. As
> >>a
> >> result,
> >> >>>>>>>>>     it’s hard for routers in one area to establish
> >> >>>>>>>>> correlations
> >> >> between
> >> >>>>>>>>>     IPv6 addresses and capabilities of routers in another
> >>area. For
> >> >>>>>>>>>     example, assume IS-IS router A in one area has established
> >> >>>>>>>>> a
> >> >> L3VPN
> >> >>>>>>>>>     session with IS-IS router B in another area over their
> >>own IPv6
> >> >>>>>>>>>     addresses. When router A needs to send L3VPN traffic to
> >> >>>>>>>>> router B
> >> >>>> via
> >> >>>>>>>>>     a MPLS-SR tunnel, router A wants to know whether router
> B
> >> >>>>>>>>> has
> >> >>>> the
> >> >>>>>>>>>     ELC (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)
> >> >>>>>>>>> before
> >> >>>>>>>>>
> >> >> <http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)%20before>
> >> >>>>>>>>>     inserting an EL into the MPLS-SR packet . However, the
> >> >> Capability
> >> >>>>>>>>>     TLV originated by router B doesn’t carried an IPv6
> >>address of
> >> its
> >> >>>>>>>>>     own. As a result, it’s hard for router A to know the ELC
> >> >>>>>>>>> of
> >> >> router B.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     Best regards,
> >> >>>>>>>>>
> >> >>>>>>>>>     Xiaohu
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     *发件人:*George, Wes
> [mailto:[e-mail]]
> >> >>>>>>>>>     *发送时间:*2014年5月2日1:51
> >> >>>>>>>>>     *收件人:*Xuxiaohu
> >> >>>>>>>>>     *抄送:*[e-mail] <mailto:[e-mail]>;
> >> >>>>>>>>>     [e-mail]
> >> >> <mailto:[e-mail]>;
> >> >>>>>>>>>     [e-mail]
> >> >>>> <mailto:[e-mail]>
> >> >>>>>>>>>     *主题:*Re: [sunset4] IPv6 router IDs
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     I got a bounce-back on all 3 draft aliases, trying again
> >>with the
> >> >>>>>>>>>     authors’s email addresses directly.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     *From: *<George>, "George, Wes"
> >> >> <[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>>
> >> >>>>>>>>>     *Date: *Thursday, May 1, 2014 at 1:42 PM
> >> >>>>>>>>>     *To: *"[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>"
> >> >>>>>>>>>     <[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>>,
> >> >>>>>>>>>     "[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>"
> >> >>>>>>>>>     <[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>>
> >> >>>>>>>>>     *Cc: *"[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>"
> >> >>>>>>>>>     <[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>>,
> >> >>>>>>>>>     "[e-mail] <mailto:[e-mail]>"
> >> >> <[e-mail]
> >> >>>>>>>>>     <mailto:[e-mail]>>
> >> >>>>>>>>>     *Subject: *[sunset4] IPv6 router IDs
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     I see that you have submitted two drafts for IPv6 router
> >> >>>>>>>>> IDs in
> >> >> ISIS
> >> >>>>>>>>>     and OSPF, noting that the existing router ID is only 4
> >>octets.
> >> This
> >> >>>>>>>>>     has also come up in IDR for BGP. The authors of that
> >>draft are
> >> >>>>>>>>>     copied. I’ll give you a similar set of feedback to what I
> >> >>>>>>>>> gave them -
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     It is important to distinguish between places where a
> >>unique
> >> >>>>>>>>>     identifier is needed, and by *convention* an IPv4 address
> >> >> assigned
> >> >>>>>>>>>     to the device has been used to provide that unique ID, vs.
> >> places
> >> >>>>>>>>>     where the actual IP address has some sort of importance to
> >> the
> >> >>>>>>>>>     protocol (I.e. That information must be available to take
> >> >>>>>>>>> action
> >> >> on).
> >> >>>>>>>>>
> >> >>>>>>>>>     In other words, is the protocol requirement that the ID be
> >> >> unique
> >> >>>>>>>>>     across some domain, but that the actual value does not
> >> >>>>>>>>> matter,
> >> >> or is
> >> >>>>>>>>>     the protocol requirement that the value must correspond
> to
> >> >>>> something
> >> >>>>>>>>>     on the router? In many of the former cases, the fact that
> >> >>>>>>>>> the
> >> >> value
> >> >>>>>>>>>     isn’t relevant has been used to make recommendations
> that
> >> >>>>>>>>> are
> >> >>>> easier
> >> >>>>>>>>>     for humans to deal with (I.e. Tying the router ID to an IP
> >> >> address)
> >> >>>>>>>>>     but that value as a human-readable set of info does not
> >> >> necessarily
> >> >>>>>>>>>     justify  changes to the protocol to support that
> >> >>>>>>>>> convention as
> >> >> we
> >> >>>>>>>>>     move to IPv6.
> >> >>>>>>>>>
> >> >>>>>>>>>     I would argue that the router ID used in routing protocols
> >> must
> >> >>>>>>>>>     merely be unique, but it doesn’t have to be an IP address
> >>at
> >> all.
> >> >>>>>>>>>     Thus it is not strictly necessary to create a new field
> >>to carry
> >> >>>>>>>>>     IPv6 addresses when operating without IPv4 addresses on
> a
> >> >>>> network.
> >> >>>>>>>>>     If you believe otherwise, the justification needs to be
> >> >> documented
> >> >>>>>>>>>     in the draft.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     There are many places in IETF protocols where a 32 bit
> >>unique
> >> >>>>>>>>>     identifier is needed, and by convention an IPv4 address
> >> >>>>>>>>> has
> >> >> been
> >> >>>>>>>>>     used. It would be far more useful to write a general draft
> >> >>>>>>>>>     identifying this problem and discussing several solutions,
> >> >> including
> >> >>>>>>>>>     simply generating unique IDs manually, systematically
> >> >> generating a
> >> >>>>>>>>>     random ID, etc.  the place for such a draft may be in
> >>Sunset4,
> >> >>>>>>>>>     either as a part of the existing gap analysis draft or as
> >>another
> >> >>>>>>>>>     standalone draft.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     There was rather a long discussion about this on IDR,
> >>thread
> >> >>>>>>>>>     here:
> >> >>>>>>>>> https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=idr
> >> >>>>>>>>> &q
> >> >>>>>>>>> =%
> >> >>>>>>>>> 22
> >> >>>>>>>>> %5
> >> >>>>>>>>> Bidr%5D+%5Bv6ops%5D+BGP+Identifier%22&as=1&gbt=1
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     And in the IDR meeting, minutes:
> >> >>>>>>>>>
> >> >>>>>>>>>
> http://www.ietf.org/proceedings/89/minutes/minutes-89-idr
> >> >>>>>>>>> (see page 11)
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     I’d encourage the authors of these drafts to work together
> >> >>>>>>>>> on
> >> >> this.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     Thanks,
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     Wes George
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>     Anything below this line has been added by my company’s
> >> >>>>>>>>> mail
> >> >>>> server,
> >> >>>>>>>>>     I have no control over it.
> >> >>>>>>>>>
> >> >>>>>>>>>     -----------
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> --------------------------------------------------------------
> >> >>>>>>>>> --
> >> >>>>>>>>> --
> >> >>>>>>>>> --
> >> >>>>>>>>> --
> >> >>>>>>>>> --
> >> >>>>>>>>>
> >> >>>>>>>>>     This E-mail and any of its attachments may contain Time
> >> >>>>>>>>> Warner
> >> >>>> Cable
> >> >>>>>>>>>     proprietary information, which is privileged,
> >>confidential, or
> >> >>>>>>>>>     subject to copyright belonging to Time Warner Cable. This
> >> >> E-mail is
> >> >>>>>>>>>     intended solely for the use of the individual or entity
> >>to which
> >> it
> >> >>>>>>>>>     is addressed. If you are not the intended recipient of
> >>this
> >> E-mail,
> >> >>>>>>>>>     you are hereby notified that any dissemination,
> >>distribution,
> >> >>>>>>>>>     copying, or action taken in relation to the contents of
> >>and
> >> >>>>>>>>>     attachments to this E-mail is strictly prohibited and may
> >>be
> >> >>>>>>>>>     unlawful. If you have received this E-mail in error,
> >>please notify
> >> >>>>>>>>>     the sender immediately and permanently delete the
> original
> >> >>>>>>>>> and
> >> >>>> any
> >> >>>>>>>>>     copy of this E-mail and any printout.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> _______________________________________________
> >> >>>>>>>>> sunset4 mailing list
> >> >>>>>>>>> [e-mail]
> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sunset4
> >> >>>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> OSPF mailing list
> >> >>>>>>> [e-mail]
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/ospf
> >> >>>>> _______________________________________________
> >> >>>>> OSPF mailing list
> >> >>>>> [e-mail]
> >> >>>>> https://www.ietf.org/mailman/listinfo/ospf
> >> >>>>>
> >> >>> _______________________________________________
> >> >>> OSPF mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/ospf
> >> >>
> >> >> _______________________________________________
> >> >> Isis-wg mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/isis-wg
> >> > _______________________________________________
> >> > Isis-wg mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/isis-wg
> >