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

[Gyan Mishra <[e-mail]>]

Hi Igor

Many thanks to your questions to clarify points in the draft.

Responses in-line Gyan>

On Sun, Jul 30, 2023 at 8:40 AM 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.
>

Gyan> I was referring to the bottom of stack service labeling of the IPv4
customer prefixes which the traffic flows are within the payload of packet
and not the label stack.  I can change the verbiage to labeled traffic.
Good point.

>
> "*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.
>

    Gyan> What I am describing is the native IPv4 prefixes under the
topmost transport IPv6 label once popped that are exposed which the
protocol is IPv4, where  the core P nodes are IPv6 so the IPv4 Paulo’s
packets will be dropped.  Imagine the scenario where you have an IPv4 core
and have native IPv4 to the edge so in that case you would have native IPv4
Unicast prefixes 1/1 over a IPv4 core IPv4 LSP topmost label, and with IPv6
core IPv6 LSP topmost label would have native IPv4 Unicast prefixes 1/1
over IPv6 core.  I can rewrite as “Native IPv4 prefixes are exposed and non
routable and IPv4 payload traffic is dropped. RFC 3032 section 2.2 states
that the bottom of stack prefixes if a different protocol  then the topmost
label as in this case must be labeled to identify the protocol type of the
prefixes.  We can discuss the other options.

>
> "*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.
>

   Gyan> Issue arises if one vendor uses arbitrary label and the other
vendor uses IPv4 explicit null label value 1. AFAIK  Both sides using to
arbitrary value or both sides signaling explicit null is ok but with
mismatch there is an issue.

>
> "*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.
>

   Gyan> Yes please clarify

>
>
> "*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.
>

Gyan> It’s just for reference stated explicitly in the draft but I agree it
can be removed

>
>
> 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.
>

   Gyan>  RFC 3031 is referenced for MPLS data plane but I did not specify
LDP spec which I can add to be consistent.  Further down in the draft I do
mention RSVP-TE but forgot to mention in above text so will add.

>
>
> 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?
>

   Gyan> Yes it can using as you stated using BGP-LU is exactly how it’s
done with inter-as option C where the next hops are imported between the
IGP domains.  See section 7.3.2.

>
>
> 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.
>

Gyan> Agreed will fix

>
> 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.
>

Gyan> Agreed will fix

>
>
> 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.
>

Gyan> Will define and make clear

>
>
> 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.
>

  Gyan> I was speaking generically not actually but is confusing as you
stated not correct- so will fix with the LDP downstream unsolicited and
RSVP-TE DOD.

>
>
> 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.
>

     Gyan> Will fix

>
>
> 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.
>

    Gyan> Will fix

>
> 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.
>

    Gyan>Lets discuss this in more detail the use cases for not labeling.
Also the issue I mentioned in RFC 3032 section 2.2 that describes the
problem with not labeling the prefix if the protocol is different between
the topmost label and service prefix.

>
>
> 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.
>

  Gyan> I am referring to BGP SAFI in this case IPv4 labeled unicast 1/4
which should say “advertised” and not “forwarded”

>
>
> 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?
>

   Gyan> yes two ships in the night two different scenarios will fix

>
>
> 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.
>

   Gyan> Yes that’s correct and will add that scenario of multiple domains
to the wording for end to end scenario

>
>
> 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.
>

   Gyan> Agreed.

>
>
> 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.
>

   Gyan> Agreed will fix

>
> 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?
>

    Gyan> The reason for IPv6 explicit null label for topmost label is to
prevent the drop issue in case the service prefix is not labeled as I have
mentioned in the draft and the IPv4 traffic is dropped.  Using IPv6
explicit null label RFC 3270  pipe mode also fixes the MPLS QOS issue of
EXP PHB scheduling on PHP node when the topmost label is popped as
mentioned earlier.

>
>
> 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.
>

    Gyan> I agree most vendors use arbitrary label by default and an option
to use explicit null.  As it’s an easy configuration change to use explicit
null with its benefits why not mandate it with the benefits.  As well as
solve issues with mix of arbitrary and explicit null usage.  I would like
to highlight that there would not be PHP but AFAIK that can only be done if
using explicit null. As well as explicit null pipe mode solves the MPLS QOS
PHB EXP scheduling issue.

>
>
> 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.
>

    Gyan> The IPv4 labeled prefixes AFAIK would have a single label per CE
or per VRF. Can you elaborate on why not possible?

>
> 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.
>

   Gyan> 7.3.1 Opt-B I mentioned that labeled unicast RIB is maintained on
ASBR but as you stated in the details is LFIB and not RIB agreed is more
optimized as what some vendors do by default both RIB and LFIB. Agreed.

>
> 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?
>

 Gyan>  It does not.  It’s just explicitly stating the next hop encoding
used.  So this section could be deleted.  As the next hop encoding is
critical I had added the section explicitly.

>
>
> 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.
>

    Gyan> I can add that to security considerations

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.
>


    Gyan> Understood I can add to the security considerations section

>
>
> 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
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*