Re: [Idr] Fwd: [E] New Version Notification for draft-mishra-idr-v4-islands-v6-core-4pe-05.txt

[Robert Raszuk <[e-mail]>]

Gyan,

All of the below elements are configuration options for already defined
standards track RFCs

Last time I checked IDR nor any other IETF WG is not tasked to standardize
specific configuration choices.

Kind regards,
Robert


On Mon, Jul 31, 2023 at 7:47 AM Gyan Mishra <[e-mail]> wrote:

>
> Hi Robert
>
> As I had mentioned during the IDR meeting update and exactly the
> discussion being had with Igor that there are a lot of procedural details
> in the draft that if not standardized could result in interoperability
> issues.
>
> RFC 4798 6PE was standardized and for good reason and following suit here
> to provide vendor interoperability this 4PE draft should be standardized.
>
> A few items from this discussion thread that are good reasons for
> standardization.
>
> Arbitrary label versus explicit null debate for IPv6 LSP.
>
> Keeping the IPv4 prefixes labeled versus unlabeled
>
> Label stack depth and future MNA
>
> Support for PHP or not
>
> Support for explicit null or not
>
> 4PE data planes supported
>
> Support for LDP and RSVP-TE
>
> Let the WG decide during the adoption call but I don’t think there is any
> reason why this should not be standardized.
>
> Thanks for the comments!
>
> Gyan
>
> On Sun, Jul 30, 2023 at 3:45 PM Robert Raszuk <[e-mail]> wrote:
>
>> Hi,
>>
>> Great comments from Igor.
>>
>> And honestly I do not intend to repeat again the entire discussion on
>> this document we already have had in the past.
>>
>> But please Gyan kindly answer why you think this draft should be a
>> "Standards Track" document. You are not defining a single
>> protocol extension nor providing modifications to protocol operations. You
>> are also not asking IANA for any new type or value allocation.
>>
>> Instead the draft enumerates various ways one could in theory signal IPv4
>> reachability over networks running IPv6 in the underlay.
>>
>> And that list of options is also far from complete too as it misses the
>> number of various overlays one can build today to transparently communicate
>> over any underlay and over any provider without any action on the transit
>> network. Think of it like CSC with pure IPv6 encapsulation - no labels nor
>> SIDs of any sort needed.
>>
>> So considering the above easy alternative it can't fit to be a BCP doc as
>> provided options in the draft are neither "Best" nor "Common" and hardly
>> "Practices" :).
>>
>> Honestly what could be perhaps helpful (if authors are still interested
>> in this topic) instead of 24 pages of pretty hard to parse text a single
>> 1-2 page table comparing pros and cons of various solutions in this space
>> published as an informational RFC.
>>
>> Kind regards,
>> Robert
>>
>>
>> On Sun, Jul 30, 2023 at 2:40 PM Igor Malyushkin <[e-mail]>
>> wrote:
>>
>>> Hi Gyan,
>>>
>>> I have several questions w.r.t your draft. But first I would like to
>>> clarify some points from your summary.
>>>
>>>
>>> "*Customer IPv4 prefixes must be labeled when tunneled over IPv6 LSP*".
>>> I believe there is a misconception between the "labeled prefixes" and the
>>> "labeled traffic". Prefixes cannot be tunneled via LSPs, traffic can be.
>>> Customer IPv4 prefixes can be dissipated as vanilla IPv4 prefixes without
>>> labels. I described the reasons during the previous discussion of this
>>> document.
>>>
>>> "*If not labeled on the PHP node when the topmost label is popped the
>>> native IPv4 prefix is exposed and is not routable and will be dropped*",
>>> this sentence describes traffic, not BGP prefixes, and I'm sure we can
>>> reach the goal of having two and more labels in a stack without advertising
>>> tons of IPv4 reachability with labels. We can solely use IPv4 labeled
>>> prefixes also, as this draft describes, but there are other options too.
>>>
>>> "*RFC 7948 “6PE” states that the label bound to the IPv4 prefixes may
>>> be an arbitrary value or explicit null label which has led to vendor
>>> interoperability issues in the past*". Can you please elaborate on that
>>> topic? I know the exact opposite cases.
>>>
>>> "*4PE draft states that the IPv4 prefixes must use MPLS QOS RFC 3270
>>> Pipe mode explicit null label bound to the IPv4 prefix and MUST be used ...*".
>>> In my opinion, the idea of getting rid of arbitrary labels breaks a lot of
>>> stuff. I will clarify it later.
>>>
>>> "*Additional text clarity added related RFC 8950 next hop encoding...*".
>>> Honestly, I don't understand why. It is just a rephrase of the stuff from
>>> the original standard. Can you shed light on the necessity of this section?
>>> Maybe I'm missing something.
>>>
>>> Here and after my comments w.r.t the body of the draft.
>>>
>>> 1. Section 1. "*This document explains the "4PE" design procedures and
>>> how to interconnect IPv4 islands over a Multiprotocol Label Switching
>>> (MPLS) [RFC3031] LDPv6 enabled IPv6-Only core, Segment Routing (SR) enabled
>>> SR-MPLS [RFC8660] IPv6-Only core or SRv6 [RFC8986] IPv6-Only core*". Is
>>> my understanding correct that the 4PE solution does not support RSVP-TE LSP
>>> signaled to IPv6 tail-ends over an IPv6-routed core? I see LDPv6 here, but
>>> the link goes to RFC3031 which is the architecture standard that applies
>>> not only to LDP. By the way, 6PE/6vPE perfectly works with RSVP LSPs.
>>>
>>> 2. Section 1. "*The 4PE routers exchange the IPv4 reachability
>>> information transparently over the core using the Multiprotocol Border
>>> Gateway Protocol (MP-BGP) over IPv6. In doing so, the BGP Next Hop field
>>> egress PE FEC (Forwarding Equivalency Class) is used to convey the IPv6
>>> address of the 4PE router learned dynamically via IGP...*". Can a 4PE
>>> router, that resides in one IGP domain, use a next-hop address received
>>> from the other domain via, for example, IPv6 labeled unicast?
>>>
>>> 3. Section 1. "...* over an MPLS [RFC3031] LDP IPv6 core, Segment
>>> Routing SR-MPLS [RFC8660] IPv6 core or SRv6 [RFC8986] IPv6 core*". This
>>> part is a repetition of the same that was done previously, and it will be
>>> repeated several times later. Moreover, there are standard numbers enclosed
>>> after every term again and again. As I understand, it is enough to do it
>>> one time per every desired abbreviation during the whole body.
>>>
>>> 4. Section 1. "*The approach requires that the Provider Edge (PE)
>>> routers Provider Edge - Customer Edge (PE-CE) connections to Customer Edge
>>> (CE)*". Honestly, it is difficult to read such things. From my POV,
>>> there should be a section with all unique definitions pertaining to this
>>> draft (e.g., 4PE router). Moreover, things such as the PE, and CE are
>>> well-known and do not require unfolding. There is a document of such
>>> well-known terms on the IETF portal for your convenience. The last thing,
>>> as I see the same abbreviations are unfolded many times during the
>>> document, which is contrary to the idea of an abbreviation in general. Once
>>> explained, an abbreviation should be used without further explanation.
>>>
>>> 5. Section 3. "*...the 4PE IPv6 address Loopback0 MUST to be routable
>>> within the IPv6 core*". What is "the 4PE IPv6 address Loopback0"? It
>>> was not previously defined in the document.
>>>
>>> 6. Section 3. "*Every ingress 4PE router can signal an IPv6 MPLS
>>> [RFC3031] LSP, SRMPLS [RFC8660] LSP or instantiate an SRv6 Best Effort (BE)
>>> or Segment Routing Traffic Engineering (SR-TE) [RFC9256] path to send to
>>> any egress 4PE router*". It is not necessary for an ingress router to
>>> signal an LSP. For example, LDP DU signals LSPs from a downstream towards
>>> all possible upstreams. RSVP or LDP DoD acts the opposite (if we talk about
>>> the intention, not a label distribution). So it is better to rephrase this
>>> sentence as "every ingress 4PE router can have an LSP toward..." or
>>> something like that.
>>>
>>> 7. Section 3. "*...the IPv6 signaled next hop Loopback0 used to
>>> identify the Ingress and Egress 4PE router*". Now the Loopback0 is
>>> somehow connected to some next-hop. I believe this connection should be
>>> clarified too.
>>>
>>> 8. Section 3. "*In doing so, the 4PE routers convey their IPv6 address
>>> FEC label binding as the BGP Next Hop for the advertised IPv4 prefixes*".
>>> The term FEC is pretty general, but the "IPv6 address FEC label binding"
>>> can mislead a reader. From my POV, this term is related to LDP, but the
>>> document includes many options to signal transport paths.
>>>
>>> 9. Section 3. "*The ingress and egress 4PE router MUST bind a label to
>>> the IPv4 prefix as per [RFC8277] using BGP Labeled Unicast herinafter
>>> called BGP-LU, AFI/SAFI Address Family (AFI) / Subsequent Address Family
>>> Identifier (SAFI) 2-tuple "1/4"*".  Which is the IPv4 prefix? If I
>>> understand it correctly, this requirement is too strict. As a designer I
>>> don't want to send all IPv4 prefixes with labels in every case, I want to
>>> have some flexibility. Moreover, as a part of the implementation team, I'm
>>> sure we won't consider this as the only possible option too.
>>>
>>> 10. Section 3. "*The Ingress 4PE router MUST forward IPv4 NLRI as
>>> Labeled prefixes using BGP-LU SAFI over the IPv6-signaled LSP towards the
>>> Egress 4PE router identified by the IPv4 address advertised in the IPv6
>>> next hop encoding per [RFC8950]*". NLRI is a term related to BGP
>>> message encoding. How can a 4PE router forward an NLRI over an LSP?
>>> Forwarding is a procedure of transmitting traffic, LSP is a transport
>>> entity used for forwarding labeled traffic, not NLRIs.
>>>
>>> 11. Section 4. "*To ensure interoperability between routers that
>>> implement the 4PE design over MPLS [RFC3031] LDP IPv6 Core described in
>>> this document, ingress and egress 4PE MUST support building the underlay
>>> tunneling using IPv6-signaled MPLS LSPs established by LDP [RFC5036] or
>>> Resource Reservation Protocol (RSVP-TE) [RFC3209]*". Here we see that
>>> RSVP is anyhow possible, but I'm still missing the idea of "MPLS LDP IPv6
>>> Core" and how RSVP is related to it. Is this sentence about LDP over RSVP
>>> tunneling? Or about ships in the night?
>>>
>>> 12. Section 4. "*The (outer) label imposed MUST correspond to the IPv6-
>>> signaled LSP starting on the ingress 4PE Router and ending on the egress
>>> 4PE Router*". What if I have segmented LSPs among several domains of
>>> the same AS? Pretty sure that in this case, the outermost label would
>>> correspond to an LSP either from an ingress 4PE to an ABR or from an ABR to
>>> the other ABR/egress 4PE router.
>>>
>>> 13. Section 4. "*The reason for the use of a second level bottom of
>>> stack service label...*". I'm sure that the stack can be deeper. I made
>>> some hints earlier in my notes (e.g., see the previous bullet), also you
>>> can think about emerging MNA solutions. I think it is better to pay
>>> attention not to the number of labels in a stack but to the fact that the
>>> bottom label must pertain to an LSP forwarding IPv4 traffic and that this
>>> label must be present on the egress.
>>>
>>> 14. Section 4. "*...it allows for Penultimate Hop Popping (PHP) on the
>>> IPv6 Label Switch Router (LSR) Provider (P) node,...*". I believe it is
>>> better to use one terminology, either pertaining to an MPLS LSP (LER/LSR)
>>> or a BGP service (P/PE) in a single sentence. Here MPLS-related terms suit
>>> you better because you are describing an LSP and label stack.
>>>
>>> 15. Section 4. "*The label advertised by the egress 4PE Router with
>>> MP-BGP MUST be an explicit Null label Pipe mode Diff-Serv Tunneling Model
>>> use case as defined in [RFC3270], so that the topmost label can be
>>> preserved Ultimate Hop POP (UHP) to the egress PE Edge LSR*". Why can
>>> it be an arbitrary label instead an explicit null?
>>>
>>> 16. Section 4. "*The explicit null label advertised by the egress PE
>>> router with MP-BGP also identifies the IPv4 routing context or outgoing
>>> interface to forward the packet to and ingress 4PE Router which MUST be
>>> able to be accept the "IPv6 Explicit NULL Label" advertised*".  From
>>> the very beginning of this statement, I understand that the egress PE
>>> advertises an explicit label (0) for IPv4-labeled unicast routes to
>>> identify either IPv4 routing context or outgoing interface. The end of this
>>> sentence tells us that the ingress 4PE router must accept the IPv6 explicit
>>> label (2). This label (2) cannot be used to identify either IPv4 routing
>>> contexts or any interfaces. So I made an assumption that there is a mistake
>>> and this is actually a 0 label, not 2.
>>> How can the label with the same value (0) identify several things
>>> (context, interface)? If you offer to bind this label to an exact interface
>>> (without a route lookup at egress) instead of doing a lookup in the global
>>> routing context/table, it will break the idea behind this special purpose
>>> label and won't support more than one interface for your solution.
>>> Arbitrary labels solve this issue and also many others.
>>> For example, it allows us to do EPE if and only if we dissipate IPv4
>>> reachability (separately from its next-hop addresses) as IPv4 routes with
>>> IPv4 next-hops alongside arbitrary labels for these next-hops distributed
>>> as labeled IPv4 routes with IPv6 next-hops (which this draft does not
>>> support and breaks). In this case, these arbitrary labels are allocated in
>>> per next-hop fashion and preclude any IP lookups at egress. I've have
>>> mentioned it several months ago.
>>>
>>> 17. Section 4. "*4PE design MUST use "IPv6 Explicit Null label" value 2
>>> defined in [RFC4182] Pipe Diff-Serv Tunneling Model as defined in [RFC3270]*".
>>> From this statement, I conclude that the authors talk about an underlying
>>> transport (IPv6 LSP via BGP LU). Why does the draft about a service mandate
>>> a label for transport? I don't see anything wrong with arbitrary labels for
>>> underlying IPv6 LSPs either. If you want to highlight that there should *not
>>> *be PHP it does not mean there is only option is an explicit label.
>>> Some vendors use arbitrary labels by default with an option to use a label
>>> of 2 instead.
>>>
>>> 18. Section 4. "*BGP/MPLS VPN [RFC4364] defines 3 label allocation
>>> modes for Layer 3 VPN's...*" and later "*The 4PE design provides the
>>> same operator flxeiblity as BGP/MPLS VPN [RFC4798], 2 level label stack
>>> option using Per-CE label allocation mode where the next hop is label so
>>> all prefixes associated with CE get the same label. The 4PE design provides
>>> the same operator flxeiblity as BGP/MPLS VPN [RFC4798], 2 level label stack
>>> option using Per-VRF label allocation mode where all prefixes within a VRF
>>> get the same is label*". I believe it is not possible with an explicit
>>> label for an IPv4 LSP either because a single value cannot be attached to
>>> many different things at the same time.
>>>
>>> 19. Section 7.3.1. "*...the 4PE IPv4 BGP-LU labeled Unicast RIB is not
>>> maintained on the ASBR*". I would further elaborate on this point as
>>> these routes must not be installed in the forwarding table as some vendors
>>> do it by default because it breaks the whole idea of the Option B scenario.
>>> Only their labels must be installed into LFIB. With the VPN-based option B
>>> there is no any danger because we do not create VRFs on an ASBR, but with
>>> labeled unicast this is a possible issue.
>>>
>>> 20. Section 8. RFC 8950 describes the logic of how to handle next-hop
>>> addresses with different lengths including the routes of SAFI 4. Does this
>>> section bring something new?
>>>
>>> 21. I don't see any description of a scenario when some vendors install
>>> specific routes in auxiliary tables for the sake of further BGP NH
>>> resolution and consider them as LSPs. There should be a warning at least.
>>> Let's imagine a case where there are two or more BNG routes residing in
>>> a single PoP. The core network is single-stack IPv6. BNGs are dual-stacked
>>> because we are still supporting some legacy connections for v4 eyeballs. PE
>>> routes that are connected to these BNGs are dual-stacked too (you can
>>> consider a BNG as a CE router). Now we want to distribute tons of /32 among
>>> PEs because the BNGs share the same IPv4 subnets. That facilitates more
>>> optimal allocation of the depleting IPv4 address space and is a pretty
>>> common case in the SP world. So, if the PE routers distribute these
>>> specifics by mistake or by design (let's say, to other PEs of this PoP for
>>> CG-NAT purposes) as IPv4 labeled unicast routes. Possible receivers of
>>> these routes may consider them viable LSPs. Imagine of hundreds thousands
>>> of such prefixes. That's actually another reason why labeled unicast is not
>>> good at this task.
>>>
>>>
>>> Thank you in advance.
>>> Igor.
>>>
>>> чт, 27 июл. 2023 г. в 19:50, Gyan Mishra <[e-mail]>:
>>>
>>>> All
>>>>
>>>> I have updated the IDR draft below updates as reviewed during our IETF
>>>> 117 meeting.
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/05/
>>>>
>>>>
>>>>    - Customer IPv4 prefixes must be labeled when tunneled over IPv6
>>>>    LSP.  If not labeled on the PHP node when the topmost label is popped the
>>>>    native IPv4 prefix is exposed and is not routable and will be dropped
>>>>    unless RFC 3270 Pipe mode explicit null signaling is enabled, which may not
>>>>    be always the case for customers wanting to use PHP signaling implicit
>>>>    null.  For IPv6 prefixes over an IPv6 core or IPv4 prefixes over IPv4 core
>>>>    at PHP node the IPv4 or IPv6 prefix can still be routed since the protocol
>>>>    of the tunneled prefix matches underlay protocol.  Not the case for 4PE
>>>>    with protocol mismatch between 2 level label stack topmost IPv6 label and
>>>>    BOS S bit IPv4 prefixes.
>>>>    - Label stack MUST be 2 Level Label Stack is only supported.  This
>>>>    is for interoperability as additional labels could be added for flexibility
>>>>    to the specification but that could break interop.  IPv4 prefixes must
>>>>    still be labeled even with MPLS QOS explicit null label pipe mode RFC 3270
>>>>    as described in RFC 3032.
>>>>    - RFC 7948 “6PE” states that the label bound to the IPv4 prefixes
>>>>    may be an arbitrary value or explicit null label which has led to vendor
>>>>    interoperability issues in the past.   4PE draft states that the IPv4
>>>>    prefixes must use MPLS QOS RFC 3270 Pipe mode explicit null label bound to
>>>>    the IPv4 prefix and MUST be used to signal from egress 4PE to ingress 4PE
>>>>    router that the packet is an IPv4 packet to identify the IPv4 routing
>>>>    context or outgoing interface to forward the packet.
>>>>    - When RFC 7948 “6PE” was written when Segment Routing did not
>>>>    exist.  The 4PE draft provides a detailed interworking of how 4PE is
>>>>    implemented with Segment Routing both SR-MPLS & SRv6.  I have cleaned up
>>>>    the related text in the draft on Segment Routing support to make it more
>>>>    clear.
>>>>    - Additional text clarity added related RFC 8950 next hop encoding
>>>>    interaction with 4PE and the importance of 4PE procedures and that RFC 8950
>>>>    is strictly about the next hop encoding of IPv4 NLRI over an IPv6 next hop
>>>>    peer.
>>>>    - Added comments related to alternatives to 4PE that exist to
>>>>    connect IPv4 islands over an IPv6 core and why a standardized BGP based 4PE
>>>>    specification is the desired solution as compared to alternatives that
>>>>    exist today.
>>>>
>>>>
>>>> Please review and provide any comments.
>>>>
>>>> Thank you
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: <[e-mail]>
>>>> Date: Thu, Jul 27, 2023 at 11:23 AM
>>>> Subject: [E] New Version Notification for
>>>> draft-mishra-idr-v4-islands-v6-core-4pe-05.txt
>>>> To: Adam Simpson <[e-mail]>, Gyan Mishra <
>>>> [e-mail]>, Jeff Tantsura <[e-mail]>,
>>>> Mankamana Mishra <[e-mail]>, Shuanglong Chen <
>>>> [e-mail]>, Sudha Madhavi <[e-mail]>
>>>>
>>>>
>>>>
>>>> A new version of I-D, draft-mishra-idr-v4-islands-v6-core-4pe-05.txt
>>>> has been successfully submitted by Gyan Mishra and posted to the
>>>> IETF repository.
>>>>
>>>> Name:           draft-mishra-idr-v4-islands-v6-core-4pe
>>>> Revision:       05
>>>> Title:          Connecting IPv4 Islands over IPv6 Core using IPv4
>>>> Provider Edge Routers (4PE)
>>>> Document date:  2023-07-27
>>>> Group:          Individual Submission
>>>> Pages:          24
>>>> URL:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe-2D05.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=nt2Ly9ZOC094SqRgkAoslAoIF6Pp9RgKbxqqksJcfI4&e=
>>>> Status:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=DJfC1DqgQ5IVWI3g7_N3FAyCnmJzFOeSCg3YcxYobjw&e=
>>>> Htmlized:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=F_Wr8Fgqdm8T5fOlOYkhpHlYyUs3dJU1xXOA9ouUDTU&e=
>>>> Diff:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe-2D05&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=fTNPBdbUKuSCsofECeey7RGCd80t507kdsJP931effo&e=
>>>>
>>>> Abstract:
>>>>    As operators migrate from an IPv4 core to an IPv6 core for global
>>>>    table internet routing, the need arises to be able provide routing
>>>>    connectivity for customers IPv4 only networks.  This document
>>>>    provides a solution called 4Provider Edge, "4PE" that connects IPv4
>>>>    islands over an IPv6-Only Core Underlay Network.
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *IT Technologist & Innovations Specialist*
>>>>
>>>> *Associate Fellow-Network Design*
>>>>
>>>> *Network Solutions A**rchitect, *
>>>>
>>>> *R&S, SP SME & Protocol Design Expert*
>>>>
>>>> *Global Technology Services*
>>>>
>>>>
>>>>
>>>> *O 240 970-6287M 301 502-1347*
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions A**rchitect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>>
>>>>
>>>> *M 301 502-1347*
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>