Re: Size of CR in CRH

[Brian E Carpenter <[e-mail]>]

Joel,

The difference I see is that (according to what I've been able to
understand about the SRH model, and extrapolating to the CRH model)
the labels don't just map to next-hop address but also to some
specific service or action tied to the label. In fact RFC8402
says this explicitly (emphasis added):

   Segment: an *instruction* a node executes on the incoming packet (e.g.,
   forward packet according to shortest path to destination, or, forward
   packet through a specific interface, or, *deliver the packet to a
   given application/service instance*).

   SID: a segment identifier.  Note that the term SID is commonly used
   in place of the term "Segment", though this is technically imprecise
   as it overlooks any necessary translation.

So a SID value has semantics mapped to actions. This is the bit that
doesn't seem to me is interoperable without more specification.

If this doesn't apply to CRH, I apologise for being off topic.

Regards
   Brian

On 22-May-20 15:37, Joel M. Halpern wrote:
> Well, it seeeems to work for MPLS without our having written that text :-)
> 
> If you assume a central controller / NMS model (there are other models), 
> then the controller needs to understand what range of CRH entry values 
> each node in the domain can understand (if we use 32 bit values, not all 
> devices will support the same subset of 2 billion entries).  It has to 
> know how (YANG model?  Other mechanisms?) to tell each node how to 
> handle the entries it is responsible for.  And it needs to know what 
> range the node can use for strict hops.
> 
> How it gets that information has always been quite variable.  For SR, 
> people tend to assume it is advertised in routing, but even for SR that 
> is not strictly required.
> 
> Yours,
> Joel
> 
> 
> On 5/21/2020 11:04 PM, Brian E Carpenter wrote:
>> Joel,
>> On 22-May-20 12:21, Joel M. Halpern wrote:
>>> Robert, local signifance has a very clear meaning in this space.  We
>>> understand it in MPLS.  We understand it in SRv6.
>>> And in neither case does it mean that nodes can make up any old label,
>>> and use it any old way, without suitable communication / coordination.
>>>
>>> However, equally, the exact coordination depends upon the control
>>> mechanism and indications one wants to use.  For example, if local
>>> labels always follow global labels which indicate their presence, then
>>> sure, you can use almost any value.  But if the disciple or pattern is
>>> different, then different constraints apply.
>>>
>>> So just what are you trying to ask?
>>
>> I'm not sure what Robert's question is. Mine is something like this:
>>
>> If the local domain contains routers from vendor A, routers from
>> vendor B, and a management system from C, what are the minimum
>> rules about the label's format and semantics that must be followed
>> to guarantee interoperability? In other words, C needs to be able
>> to tell both A routers and B routers the same thing in order to
>> set up their CRH-FIBs.
>>
>> A supplementary question is: Should those rules be specified in
>> the basic CRH draft, or in a separate document?
>>
>> (I have a similar question about the SRH work, but it probably
>> doesn't belong here.)
>>
>> Regards
>>     Brian
>>
>>>
>>> Yours,
>>> Joel
>>>
>>> On 5/21/2020 6:29 PM, Robert Raszuk wrote:
>>>> Hi Ron,
>>>>
>>>> I don't think we need to go through a tutorial here what the FIB,
>>>> CRH-FIB or LFIB is.
>>>>
>>>> I asked specific question on which you have not provided any answer:
>>>>
>>>> If I have part of the network non CRH aware and each node is free to
>>>> allocate their own SID - as you are claiming SIDs are locally
>>>> significant - how would the CRH look like in case of SID conflict
>>>> between local node and remote node SID collision.
>>>>
>>>> Now rest of your answer is rather vague at best. And this is not just a
>>>> detail. This is fundamental frame to the proposal we are discussing
>>>> adoption of.
>>>>
>>>> Sure once document becomes a WG a collective brains can paint it well -
>>>> but if it does not even have solid frames it may be a pretty hard task.
>>>>
>>>> Just my own little side input. Others may see it different way,
>>>>
>>>> Many thx,
>>>> R.
>>>>
>>>>
>>>> On Fri, May 22, 2020 at 12:22 AM Ron Bonica <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>      Robert,____
>>>>
>>>>      __ __
>>>>
>>>>      I think that you are confusing two data structures. The CRH-FIB is
>>>>      just that, a FIB. I contains enough information to resolve an
>>>>      incoming identifier to an IPv6 address and a forwarding method. Each
>>>>      node maintains a unique CRH-FIB and there is no requirement for
>>>>      nodes to share their CRH-FIBs with one another. The CRH-FIB lives on
>>>>      the forwarding plane and is an appropriate topic for 6man.____
>>>>
>>>>      __ __
>>>>
>>>>      Somewhere in the network, there is an entity constructs the CRH and
>>>>      the list that it contains. That entity needs access to another data
>>>>      structure, that includes a global view of each node’s CRH-FIB. That
>>>>      entity might be:____
>>>>
>>>>      __ __
>>>>
>>>>        * A human, manually constructing forwarding policy____
>>>>        * A controller____
>>>>        * Path computation software on a router.. ____
>>>>
>>>>      __ __
>>>>
>>>>                                                                                                              Ron____
>>>>
>>>>      __ __
>>>>
>>>>      __ __
>>>>
>>>>      __ __
>>>>
>>>>      Juniper Business Use Only____
>>>>
>>>>      *From:* Robert Raszuk <[e-mail] <mailto:[e-mail]>>
>>>>      *Sent:* Thursday, May 21, 2020 4:05 PM
>>>>      *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>
>>>>      *Cc:* 6man <[e-mail] <mailto:[e-mail]>>
>>>>      *Subject:* Re: Size of CR in CRH____
>>>>
>>>>      __ __
>>>>
>>>>      *[External Email. Be cautious of content]____*
>>>>
>>>>      __ __
>>>>
>>>>      Hello Ron,____
>>>>
>>>>      __ __
>>>>
>>>>       > Why should it? It isn’t attached to link X->Y. So it couldn’t use
>>>>      that entry even if it had it. ____
>>>>
>>>>      __ __
>>>>
>>>>      This question I think exposes or uncovers (at least for me) the crux
>>>>      of your proposal ... perhaps even fatal one. ____
>>>>
>>>>      __ __
>>>>
>>>>      You are assuming that only locally allocated SIDs are in CRH-FIB -
>>>>      that is fatal assumption for bunch of reasons ... one swapping DA to
>>>>      some node N hops away. How are you going to accomplish that if such
>>>>      entries are not even in CRH-FIB ? ____
>>>>
>>>>      __ __
>>>>
>>>>      I guess it is very clear now why the other day you stated that "all
>>>>      nodes in the domain must support CRH". ____
>>>>
>>>>      __ __
>>>>
>>>>      What seems you are doing here ... and of course this is not written
>>>>      anywhere in any document ... so this is pure acceptance call
>>>>      guessing - is a forward referencing SIDs against the peers. ____
>>>>
>>>>      __ __
>>>>
>>>>      So on any node you are allocating SID per interface -
>>>>      strictly speaking per forwarding adjacency. Clearly you can not
>>>>      build such construct for remote nodes based on the above. ____
>>>>
>>>>      __ __
>>>>
>>>>      Furthermore you are building forwarding chain on the basis of
>>>>      ordered forwarding list of SIDs just hoping that the peer will
>>>>      accept the packet if his DA address is in the IPv6 header. Then it
>>>>      will look up his own SID and continue. ____
>>>>
>>>>      __ __
>>>>
>>>>      One thing I must agree with you that this is not Segment Routing ...
>>>>      In fact I am not sure how to call this architecture. Maybe forward
>>>>      referenced source routing ? ____
>>>>
>>>>      __ __
>>>>
>>>>      You can not do TI-LFA with this approach unless you pre-program any
>>>>      possible alternative paths to all nodes in the network. ____
>>>>
>>>>      __ __
>>>>
>>>>      Sure you can demo this in the lab or even on a network just like you
>>>>      could demo static mpls labels. Yes it is very simple and you got
>>>>      attention of few folks with that. And yes you could perhaps even
>>>>      show that if you just add few lines of xml config you could tunnel
>>>>      it across non CRH capable nodes ... But is this solution for any
>>>>      production network ? ____
>>>>
>>>>      __ __
>>>>
>>>>      I think and I was told by unicast emails that I am not alone - we
>>>>      are just guessing what the vehicle looks like after seeing the first
>>>>      wheel. So far it does not even look like a car ... maybe bike or
>>>>      scooter. Who knows .... ____
>>>>
>>>>      __ __
>>>>
>>>>      If I may recommend next action without dismissing your proposal a
>>>>      wise thing to do would be to get from you set of slides or perhaps
>>>>      youtube recording showing exactly not only all mapping distribution,
>>>>      but more over illustrating exact packet's header including CRH in
>>>>      all various cases I and others asked when packet is
>>>>      traversing throughout a controlled domain.____
>>>>
>>>>      __ __
>>>>
>>>>      Only after that we could start a new adoption call when more folks
>>>>      actually has a clear picture what it is being adopted here. Is it a
>>>>      brilliant and cool solution or is it some form of wild animal which
>>>>      can bite. ____
>>>>
>>>>      __ __
>>>>
>>>>      Many thx,____
>>>>
>>>>      Robert.____
>>>>
>>>>      __ __
>>>>
>>>>      __ __
>>>>
>>>>      On Thu, May 21, 2020 at 9:46 PM Ron Bonica <[e-mail]
>>>>      <mailto:[e-mail]>> wrote:____
>>>>
>>>>          Robert,____
>>>>
>>>>          ____
>>>>
>>>>          I am assuming that B is attached to Z. When I say, it isn’t
>>>>          attached, I mean that B isn’t attached to Link X->Y. Link X->Y
>>>>          is attached to Z.____
>>>>
>>>>          ____
>>>>
>>>>                                                                                                         Ron____
>>>>
>>>>          ____
>>>>
>>>>          ____
>>>>
>>>>          ____
>>>>
>>>>          Juniper Business Use Only____
>>>>
>>>>          *From:* Robert Raszuk <[e-mail]
>>>>          <mailto:[e-mail]>>
>>>>          *Sent:* Thursday, May 21, 2020 3:14 PM
>>>>          *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>
>>>>          *Cc:* 6man <[e-mail] <mailto:[e-mail]>>
>>>>          *Subject:* Re: Size of CR in CRH____
>>>>
>>>>          ____
>>>>
>>>>          *[External Email. Be cautious of content]*____
>>>>
>>>>          ____
>>>>
>>>>           > It isn’t attached to link X->Y. ____
>>>>
>>>>          ____
>>>>
>>>>          Please assume it is attached. ____
>>>>
>>>>          ____
>>>>
>>>>          I stated very clearly: "(or maybe even connected to B)"____
>>>>
>>>>          ____
>>>>
>>>>          Thx,
>>>>          R.____
>>>>
>>>>          ____
>>>>
>>>>          ____
>>>>
>>>>          ____
>>>>
>>>>          On Thu, May 21, 2020 at 8:45 PM Ron Bonica <[e-mail]
>>>>          <mailto:[e-mail]>> wrote:____
>>>>
>>>>              Robert,____
>>>>
>>>>              ____
>>>>
>>>>              Identifiers have node local scope. This means:____
>>>>
>>>>              ____
>>>>
>>>>                * One a single node, there is a one-to-one mapping between
>>>>                  identifiers and the CRH-FIB entries that they identify____
>>>>                * Nodes A through Z can all have a CRH-FIB entry that is
>>>>                  identified by N. However, all of those CRH-FIB entries
>>>>                  do not need to contain the same information.____
>>>>
>>>>              ____
>>>>
>>>>              Referring back to your example, Node B will never have the
>>>>              following entry in its CRH-FIB:____
>>>>
>>>>              ____
>>>>
>>>>                * Identifier = 15, IPv6 Address = Node Z, Method = strict,
>>>>                  Link = X->Y____
>>>>
>>>>              ____
>>>>
>>>>              Why should it? It isn’t attached to link X->Y. So it
>>>>              couldn’t use that entry even if it had it.____
>>>>
>>>>              ____
>>>>
>>>>                                          
>>>>                                            Ron____
>>>>
>>>>              ____
>>>>
>>>>              ____
>>>>
>>>>              ____
>>>>
>>>>              ____
>>>>
>>>>              Juniper Business Use Only____
>>>>
>>>>              *From:* Robert Raszuk <[e-mail]
>>>>              <mailto:[e-mail]>>
>>>>              *Sent:* Thursday, May 21, 2020 11:25 AM
>>>>              *To:* Ron Bonica <[e-mail]
>>>>              <mailto:[e-mail]>>
>>>>              *Cc:* 6man <[e-mail] <mailto:[e-mail]>>
>>>>              *Subject:* Re: Size of CR in CRH____
>>>>
>>>>              ____
>>>>
>>>>              *[External Email. Be cautious of content]*____
>>>>
>>>>              ____
>>>>
>>>>              Hi Ron,____
>>>>
>>>>              ____
>>>>
>>>>               > Node B decrements Segments Left and looks for entry 15 in
>>>>              **its** CRH-FIB. If finds:____
>>>>
>>>>               > ____
>>>>
>>>>               >     On Node B:  Identifier = 15, IPv6 Address = Node C,
>>>>              Method = strict, Link = B->C____
>>>>
>>>>              ____
>>>>
>>>>              Your example works when the entire network has a single
>>>>              segment routed path :) ____
>>>>
>>>>              ____
>>>>
>>>>              What happens if also Node Z somewhere in the domain (or
>>>>              maybe even connected to B) advertised SID 15 with some
>>>>              different outbound link ? ____
>>>>
>>>>              ____
>>>>
>>>>              So Node B will have two FIB entries: ____
>>>>
>>>>              ____
>>>>
>>>>                 Identifier = 15, IPv6 Address = Node C, Method = strict,
>>>>              Link = B->C ____
>>>>
>>>>                 Identifier = 15, IPv6 Address = Node Z, Method = strict,
>>>>              Link = X->Y ____
>>>>
>>>>              ____
>>>>
>>>>              So how will B decided which one to use ? ____
>>>>
>>>>              ____
>>>>
>>>>              Best,____
>>>>
>>>>              R.____
>>>>
>>>>              ____
>>>>
>>>>              ____
>>>>
>>>>              ____
>>>>
>>>>              ____
>>>>
>>>>              On Thu, May 21, 2020 at 5:11 PM Ron Bonica
>>>>              <[e-mail] <mailto:[e-mail]>> wrote:____
>>>>
>>>>                  Robert,____
>>>>
>>>>                  ____
>>>>
>>>>                  Let’s address your question with an example. Assume that
>>>>                  Node A is sending a packet to Node D. The delivery path
>>>>                  includes the following strictly routed hops:____
>>>>
>>>>                  ____
>>>>
>>>>                    * Node A to Node B over link A->B____
>>>>                    * Node B to Node C over link B->C____
>>>>                    * Node C to Node D over link C->D____
>>>>
>>>>                  ____
>>>>
>>>>                  Now we populate the CRH-FIB on Nodes B and C as follows:____
>>>>
>>>>                  ____
>>>>
>>>>                    * On Node B:  Identifier = 15, IPv6 Address = Node C,
>>>>                      Method = strict, Link = B->C____
>>>>                    * On Node C:  Identifier = 15, IPv6 Address = Node D,
>>>>                      Method = strict, Link = C->D____
>>>>
>>>>                  ____
>>>>
>>>>                  Now, Node A formats a packet as follows:____
>>>>
>>>>                  ____
>>>>
>>>>                    * IPv6 Destination Address = Node B____
>>>>                    * CRH Segments Left = 2____
>>>>                    * Identifier list = [15,15]____
>>>>
>>>>                  ____
>>>>
>>>>                  Node A sends this packet to Node B over link A->B.. Node
>>>>                  B decrements Segments Left and looks for entry 15 in
>>>>                  **its** CRH-FIB. If finds:____
>>>>
>>>>                  ____
>>>>
>>>>                    * On Node B:  Identifier = 15, IPv6 Address = Node C,
>>>>                      Method = strict, Link = B->C____
>>>>
>>>>                  ____
>>>>
>>>>                  So, Node B updates the IPv6 address and sends the packet
>>>>                  to Node C over link B->C. Node C decrements Segments
>>>>                  Left and looks for entry 15 in **its** CRH-FIB. If
>>>>                  finds:____
>>>>
>>>>                  ____
>>>>
>>>>                    * On Node C:  Identifier = 15, IPv6 Address = Node D,
>>>>                      Method = strict, Link = C->D____
>>>>
>>>>                  ____
>>>>
>>>>                  So, Node C updates the IPv6 address and sends the packet
>>>>                  to Node D over link C->D.____
>>>>
>>>>                  ____
>>>>
>>>>                                                                             Ron____
>>>>
>>>>                  ____
>>>>
>>>>                  ____
>>>>
>>>>                  ____
>>>>
>>>>                  Juniper Business Use Only____
>>>>
>>>>                  *From:* Robert Raszuk <[e-mail]
>>>>                  <mailto:[e-mail]>>
>>>>                  *Sent:* Thursday, May 21, 2020 10:35 AM
>>>>                  *To:* Ron Bonica <[e-mail]
>>>>                  <mailto:[e-mail]>>
>>>>                  *Cc:* 6man <[e-mail] <mailto:[e-mail]>>
>>>>                  *Subject:* Re: Size of CR in CRH____
>>>>
>>>>                  ____
>>>>
>>>>                  *[External Email. Be cautious of content]*____
>>>>
>>>>                  ____
>>>>
>>>>                  Ron, ____
>>>>
>>>>                  ____
>>>>
>>>>                  While we are at the local vs global significance of SIDs
>>>>                  can you please elaborate how do you resolve the conflict
>>>>                  where given SID value is advertised by more then one
>>>>                  node ? In fact imagine that all nodes in a domain choose
>>>>                  to advertise the same SID value "15" to forward the
>>>>                  traffic to their respective peers. So packet arrives at
>>>>                  segment endpoint node A with CRH consisting of SID list
>>>>                  15, 15, 15, 15 ... where each value 15 means different
>>>>                  behaviour on different node. ____
>>>>
>>>>                  ____
>>>>
>>>>                  How do you even know which way to forward the packet ? ____
>>>>
>>>>                  ____
>>>>
>>>>                  See in this case your mapping plane will contain
>>>>                  different functions on different nodes signalled with
>>>>                  the same SID. ____
>>>>
>>>>                  ____
>>>>
>>>>                  I understand that you are trying to silently borrow
>>>>                  set of procedures from SR-MPLS here as documented in
>>>>                  RFC8660. But if you just open this RFC you will see
>>>>                  section 2.5 or 2.6 without which you just can not simply
>>>>                  propose to treat SID as locally significant in any form
>>>>                  of segment routing. Of course unless you would consume
>>>>                  two SIDs per node. ____
>>>>
>>>>                  ____
>>>>
>>>>                  Thx,
>>>>                  Robert.____
>>>>
>>>>                  ____
>>>>
>>>>                  ____
>>>>
>>>>                  On Thu, May 21, 2020 at 10:34 AM Robert Raszuk
>>>>                  <[e-mail] <mailto:[e-mail]>> wrote:____
>>>>
>>>>                      Ron, ____
>>>>
>>>>                      ____
>>>>
>>>>                       > Now recall that identifiers have node local
>>>>                      significance. ____
>>>>
>>>>                      ____
>>>>
>>>>                      I was talking about case described in yr draft
>>>>                      section 7: ____
>>>>
>>>>                      ____
>>>>
>>>>                      "Applications can:____
>>>>
>>>>                      ____
>>>>
>>>>                      o Allocate SIDs so that they have *domain-wide
>>>>                      significance*."____
>>>>
>>>>                      ____
>>>>
>>>>                      While not a must - it is an option. So I believe my
>>>>                      observation stays valid till draft either removes
>>>>                      that option or describes scaling properties
>>>>                      differences between both domain wide and local
>>>>                      significance of the SIDs.____
>>>>
>>>>                      ____
>>>>
>>>>                      Thx,____
>>>>
>>>>                      R.____
>>>>
>>>>                      ____
>>>>
>>>>                      ____
>>>>
>>>>                      On Thu, May 21, 2020 at 4:01 AM Ron Bonica
>>>>                      <[e-mail] <mailto:[e-mail]>>
>>>>                      wrote:____
>>>>
>>>>                          Robert,____
>>>>
>>>>                          ____
>>>>
>>>>                          Consider the following network:____
>>>>
>>>>                          ____
>>>>
>>>>                            * Contains 65,000 routers____
>>>>                            * Each router has 500 directly connected
>>>>                              neighbors or fewer____
>>>>                            * Uses 16-bit CRH____
>>>>
>>>>                          ____
>>>>
>>>>                          In this network, each node might have 65,499
>>>>                          CRH-FIB entries:____
>>>>
>>>>                          ____
>>>>
>>>>                            * 64,999 CRH-FIB entries cause packets to
>>>>                              follow the least-cost path to another node
>>>>                              in the domain____
>>>>                            * 500 CRH-FIB entries cause packets to
>>>>                              traverse a specific link to a specific
>>>>                              neighbor.____
>>>>
>>>>                          ____
>>>>
>>>>                          As a mnemonic device, an operator might assign
>>>>                          identifiers as follows:____
>>>>
>>>>                          ____
>>>>
>>>>                            * 0-65,000 identify CRH-FIB entries that cause
>>>>                              packets to follow the least-cost path to
>>>>                              another node in the domain____
>>>>                            * 65,001 – 65,565 identify CRH-FIB entries
>>>>                              that that cause packets to traverse a
>>>>                              specific link to a specific neighbor.____
>>>>
>>>>                          ____
>>>>
>>>>                          Now recall that identifiers have node local
>>>>                          significance. So, Node A and Node B might both
>>>>                          have a CRH-FIB entry that is identified by the
>>>>                          value 65,001. However:____
>>>>
>>>>                          ____
>>>>
>>>>                            * The CRH-FIB entry on Node A causes packets
>>>>                              to traverse a particular link towards Node X____
>>>>                            * The CRH-FIB entry on Node B causes packets
>>>>                              to traverse a different link towards Node Y.____
>>>>
>>>>                          ____
>>>>
>>>>                          I think that this example refutes the premise of
>>>>                          your argument, so there is not further need to
>>>>                          address the conclusion.____
>>>>
>>>>                          ____
>>>>
>>>>                                                                                                                    Ron____
>>>>
>>>>                          ____
>>>>
>>>>                          ____
>>>>
>>>>                          ____
>>>>
>>>>                          ____
>>>>
>>>>                          Juniper Business Use Only____
>>>>
>>>>                          *From:* Robert Raszuk <[e-mail]
>>>>                          <mailto:[e-mail]>>
>>>>                          *Sent:* Wednesday, May 20, 2020 6:20 PM
>>>>                          *To:* Ron Bonica <[e-mail]
>>>>                          <mailto:[e-mail]>>
>>>>                          *Cc:* 6man <[e-mail] <mailto:[e-mail]>>
>>>>                          *Subject:* RE: Size of CR in CRH____
>>>>
>>>>                          ____
>>>>
>>>>                          *[External Email. Be cautious of content]*____
>>>>
>>>>                          ____
>>>>
>>>>                          HI, ____
>>>>
>>>>                          ____
>>>>
>>>>                          So just to make sure I understand this analogy
>>>>                          of 16 bit -- 2^16 = 65536 nodes. I think this is
>>>>                          only on paper. ____
>>>>
>>>>                          ____
>>>>
>>>>                          Imagine I have 1000 routers so if I divide the
>>>>                          16 bit space by 1000 I get at most 65 local node
>>>>                          behaviours if anyone would like to embed such
>>>>                          into the SID. ____
>>>>
>>>>                          ____
>>>>
>>>>                          That means that if my router have more then 65
>>>>                          interfaces I am not able to steer packets by src
>>>>                          route out of my router ... I must always depend
>>>>                          on the lookup of next SID how to forward the
>>>>                          packets. ____
>>>>
>>>>                          ____
>>>>
>>>>                          That also means that if I want to apply any form
>>>>                          of NP in segment endpoint I am quite limited to
>>>>                          the number of local functions I could use. ____
>>>>
>>>>                          ____
>>>>
>>>>                          To conclude - Let me restate to what I and
>>>>                          others already said - flat SID space domain wide
>>>>                          in mapping plane is a mistake. Yes this is like
>>>>                          MPLS, but this does not make it great again due
>>>>                          to that legacy. ____
>>>>
>>>>                          ____
>>>>
>>>>                          Many thx,
>>>>                          R.____
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>