lizhong.jin | 1 Jul 13:46 2011
Picon

Re: Request comments for HSMP LSP


Hi Edward, Lamberto and all,
Sorry for the later reply. And no, when apply HSMP LSP to VPLS, the path from leaf PE to root PE is exactly the shortest path. mLDP leaf will send mapping message to root node, choosing the path with routing table, and this path is the shortest path from leaf to root.

We have updated the draft with more clarification of the use cases, and added new use case of VPLS application.
You can get the new draft from link: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-03

Thank you.
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 9 Jan 2011 02:50:16 +0100
> From: Lamberto Sterling <lamberto.sterling <at> gmail.com>
> Subject: Re: [mpls] Request comments for HSMP LSP
> To: maillist.ed <at> gmail.com, lizhong.jin <at> zte.com.cn
> Cc: l2vpn <at> ietf.org, mpls <at> ietf.org, Ice <ice <at> cisco.com>,
>    tictoc <at> ietf.org,   N.Leymann <at> telekom.de
> Message-ID:
>    <AANLkTi=CbhP10iM7=wXcb=e9oV0cqwaTKjY7ArZquoW1 <at> mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi guys,
> Sorry for the email subject. Change it now.
>
> Lamberto
>
> On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling <
> lamberto.sterling <at> gmail.com> wrote:
>
> > Hi Lizhong, Edward,
> > It seems that it is a good idea to apply HSMP LSP to VPLS, and the
> > broadcast/unicast/unknow packet would be optimized. However, the path from
> > leaf to root may not be the best path compared with current VPLS using P2P
> > LSP, which is not a critical issue.
> >
> > Thanks
> > Lamberto
> >
> >
> >
> >>
> >> ------------------------------
> >>
> >>
> >> Date: Wed, 5 Jan 2011 15:50:45 +0800
> >> From: lizhong.jin <at> zte.com.cn
> >> Subject: Re: [mpls] Request comments for HSMP LSP
> >> To: Ed <maillist.ed <at> gmail.com>
> >> Cc: l2vpn <at> ietf.org, mpls <at> ietf.org, Ice <ice <at> cisco.com>,
> >>        N.Leymann <at> telekom.de,   tictoc <at> ietf.org
> >> Message-ID:
> >>        <
> >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9 <at> zte.com.cn>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> Hi Edward,
> >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with
> >> the application you proposed, and in order to improve the scalability of
> >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually
> >> this is a good application case for P2MP PW with reverse path (section
> >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
> >> use case.
> >>
> >> Regards
> >> Lizhong
> >>
> >>
> >> Ed <maillist.ed <at> gmail.com> wrote on 2011-01-05 15:05:30:
> >>
> >> > Hi Lizhong,
> >> >
> >> > I think one possible application for HSMP LSPs is to reduce the
> >> > overall broadcast/multicast utilization on a VPLS. In current VPLS
> >> > implementations with a full mesh of P2P LSPs between PEs, broadcast,
> >> > multicast and unknown traffic are not efficiently propagated on the
> >> > physical links between PEs and Ps.
> >> >
> >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals
> >> > a HSMP LSP with itself as a root to all other PEs in the VPLS.
> >> > Thereafter, all broadcast/multicast/unknown traffic from this PE
> >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
> >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> >> > the HSMP LSP where PE2 is the root.
> >> >
> >> > This simplifies the VPLS implementation by:
> >> > -          Reducing traffic utilization from broadcast, multicast
> >> > and unknown traffic
> >> > -          Reducing the total number of LSPs maintained by each PE
> >> > (i.e. instead of requiring a full mesh of LSPs, now only require one
> >> > HSMP LSP per PE).
> >> >
> >> > This is similar to the idea expressed in  draft-key-l2vpn-etree-
> >> > frwk-03.txt (in a more general sense).
> >> >
> >> > What do you think? Would HSMP LSP be suitable for this?
> >> >
> >> > Regards,
> >> > Edward
> >> >
> >> >
> >> >
> >> > On Wed, Jan 5, 2011 at 5:24 PM, <lizhong.jin <at> zte.com.cn> wrote:
> >> >
> >> > Hi all,
> >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS
> >> session.
> >> > HSMP LSP has several use cases described in the draft, e.g, time
> >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would
> >> > be appreciated if you could give more scenarios for HSMP LSP. Please
> >> > review the draft, and any comments are welcome.
> >> >
> >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> >> > mldp-hsmp-01
> >> >
> >> > Thank you.
> >> > Authors of draft-hsmp.
> >> > --------------------------------------------------------
> >> >
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/mpls/attachments/20110109/e5b476e5/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 81, Issue 12
> ************************************
>

-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Joel M. Halpern | 1 Jul 15:07 2011

Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier

In performing a gen-art review of this document, which seems quite good 
over all, I noticed a minor question, but did not remember to include it 
in my gen-art review.

The defines a Tunnel-Identifier, identifying the end-point of a tunnel 
within a node.
That identifier is defined as 16 bits.
In one sense, that seems sufficient.  But it is more restrictive than 
the number of parallel LSPs that the node could be an end-point for (by 
a factor of 16.)  So it seems that there ought to at least be an 
explanation for the mismatch.

Thank you,
Joel

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Huub van Helvoort | 1 Jul 12:00 2011
Picon

Re: ICC and CC

Hello George,

On 17-06-11 you wrote:

> And if so, do you have a suggestion for the combined fields?

Yes. After discussing the MEG-ID format on the Q10 list we have
the following format definition, the identifier

 >- consists of 13 characters, which contain:
 >- ICC (1 to 6 characters) as defined in rec. M.1400
 >- "/"
 >- CC (2 characters) as defined in ISO 3166-1 alpha-2
 >- UMC with trailing NULLs

All used characters are as defined in rec. T.50.

> I thought ICC stood for _International_ Carrier Code. M.1600 does not
> expand the acronym.

This acronym is expanded in M.1400, which is referenced in
the identifiers draft, as "ITU-T Carrier Code".
The CC above is "Country Code".
And UMC is "Unique MEG ID Code".

Regards, Huub.

> On 6/17/11 9:19 AM, "George Swallow" <swallow <at> cisco.com> wrote:
>
>     Huub, Italo, Malcolm,
>
>     I look to you guys as the authority on this. Should I prefix the ICC
>     with a CC?
>
>     Thanks,
>
>     ...George
>     ------------------------------------------------------------------------
>     _______________________________________________
>     mpls mailing list
>     mpls <at> ietf.org
>     https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

--

-- 
*****************************************************************
                          我爱外点一七三一
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: ICC and CC

Hub,
I did not see yet an agreement on the proposal in Q10.
I do not think your mail represents the ITU-T.
Best regards,
Nurit

-----Original Message-----
From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of ext Huub van Helvoort
Sent: Friday, July 01, 2011 1:00 PM
To: George Swallow
Cc: mpls <at> ietf.org; Huub van Helvoort; BUSI,ITALO (ITALO)
Subject: Re: [mpls] ICC and CC

Hello George,

On 17-06-11 you wrote:

> And if so, do you have a suggestion for the combined fields?

Yes. After discussing the MEG-ID format on the Q10 list we have
the following format definition, the identifier

 >- consists of 13 characters, which contain:
 >- ICC (1 to 6 characters) as defined in rec. M.1400
 >- "/"
 >- CC (2 characters) as defined in ISO 3166-1 alpha-2
 >- UMC with trailing NULLs

All used characters are as defined in rec. T.50.

> I thought ICC stood for _International_ Carrier Code. M.1600 does not
> expand the acronym.

This acronym is expanded in M.1400, which is referenced in
the identifiers draft, as "ITU-T Carrier Code".
The CC above is "Country Code".
And UMC is "Unique MEG ID Code".

Regards, Huub.


> On 6/17/11 9:19 AM, "George Swallow" <swallow <at> cisco.com> wrote:
>
>     Huub, Italo, Malcolm,
>
>     I look to you guys as the authority on this. Should I prefix the ICC
>     with a CC?
>
>     Thanks,
>
>     ...George
>     ------------------------------------------------------------------------
>     _______________________________________________
>     mpls mailing list
>     mpls <at> ietf.org
>     https://www.ietf.org/mailman/listinfo/mpls

>
>
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls



-- 
*****************************************************************
                          我爱外点一七三一
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
George Swallow | 1 Jul 20:39 2011
Picon

Re: Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier

The primary motivation is to allow for a compact form for the Tunnel MEP_ID.  A secondary motivation is compatibility with existing MPLS/GMPLS Session objects.

...George


On 7/1/11 9:07 AM, "Joel M. Halpern" <jmh <at> joelhalpern.com> wrote:

In performing a gen-art review of this document, which seems quite good
over all, I noticed a minor question, but did not remember to include it
in my gen-art review.

The defines a Tunnel-Identifier, identifying the end-point of a tunnel
within a node.
That identifier is defined as 16 bits.
In one sense, that seems sufficient.  But it is more restrictive than
the number of parallel LSPs that the node could be an end-point for (by
a factor of 16.)  So it seems that there ought to at least be an
explanation for the mismatch.

Thank you,
Joel

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
George Swallow | 2 Jul 00:15 2011
Picon

Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Xinchun -

This restriction was not intended.  The draft has been updated to make it clear that it is applicable to both.

,,,George


On 2/13/11 11:09 PM, "Xinchun Guo" <guoxinchun <at> huawei.com> wrote:

Hi authors and all

About this document, I have another question expect to be clarification. I
am not very clear about the specific application of Fault management
message.

In section 2 of this document, it said " Fault OAM messages are generated by
intermediate nodes where an LSP is switched".  Does it mean that the fault
message can only be used for alarm suppress of LSP layer?  Could not this
fault management function be used for PW layer, especially for the MS-PW
conditions.  Take the following hiberarchy scenario for example, PW1 and PW2
are two segments of the MS-PW which is client of the LSP layer.  if the
server layer of LSP fails, such as Link1, node2 will initiate AIS message
and sent it to LSP1 end point node3.  As MS-PW is client of LSP1, for this
condition, whether Node3 will further initiate Fault management message to
MS-PW end point Node4 to notify the failure of LSP1 to suppress alarm of the
end to end pw service.  IMO, Fault management function should cover these PW
conditions.

-                        MS-PW                   -
-                           +---------AIS/LKR-------------->>-
-<-----------------PW1-------------------->|-----------------PW2------------
>-
-              +----AIS/LKR---->>                     -
-<-------LSP1---------+-------------------><--------------LSP2--------------
->-
-              |AIS/LKR                            -
-<--- Link1---------->|<---
Link2------><--------Link3--------------------->-
Node1       Node2       Node3                Node4


Hope authors could clarify this point and detail the Fault function process
about PW scenarios in this document.

Best Regards
Xinchun


-----Original Message-----
From: mpls-tp-bounces <at> ietf.org [mailto:mpls-tp-bounces <at> ietf.org] On Behalf
Of Xinchun Guo
Sent: Friday, February 11, 2011 5:52 PM
To: 'Loa Andersson'; mpls-tp <at> ietf.org; mpls <at> ietf.org
Cc: ahmpls-tp <at> lists.itu.int
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Other 3 edit comments, see below.

1.section 2.2, there is overlapping between the last sentence of the first
paragraph and the first sentence of the second paragraph about " The purpose
of the LKR message is to suppress alarms in the MPLS-TP layer network above
the level at which the defect occurs" . Simplify it will be more smart.

2.section 4.1.2, the first sentence" This TLV carries the Interface
Identifier as defined ......", "the Interface Identifier" should be "the
Global Identifier". right?

3. section 5.3, there are two "that" in the first sentence, one is
redundancy.

Regards
Xinchun

-----Original Message-----
From: mpls-tp-bounces <at> ietf.org [mailto:mpls-tp-bounces <at> ietf.org] On Behalf
Of Xinchun Guo
Sent: Friday, February 11, 2011 9:39 AM
To: 'Loa Andersson'; mpls-tp <at> ietf.org; mpls <at> ietf.org
Cc: ahmpls-tp <at> lists.itu.int
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Dear authors

After read the document, I have a question about the FM massage procedure.

In the section 5.1, the third paragraph, it said "The message is then sent.
The message MUST be refreshed two more times at an interval of one second.
Further refreshes are sent according to the value of the refresh timer."  I
don't know why the refreshing massage must be first sent two more times in
one second and then sent as the refresh timer interval.  Is it ok if the
refreshing massage is sent only according to the value of the refresh timer?
If it is not, what problem may be introduced? Hope authors could explain it
for me.

In addition, figure 2 is about the fault management massage format, so I
think naming the figure" MPLS-TP fault Management Message Format " other
than" MPLS-TP OAM Message Format " is more suitable.

Best Regards
Xinchun

-----Original Message-----
From: mpls-tp-bounces <at> ietf.org [mailto:mpls-tp-bounces <at> ietf.org] On Behalf
Of Loa Andersson
Sent: Thursday, February 03, 2011 7:37 PM
To: mpls-tp <at> ietf.org; mpls <at> ietf.org
Cc: ahmpls-tp <at> lists.itu.int
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

Please send comments to the mpls-tp <at> ietf.org mailing list.

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson                         email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager            loa <at> pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13



_______________________________________________
mpls-tp mailing list
mpls-tp <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp



_______________________________________________
mpls-tp mailing list
mpls-tp <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp



_______________________________________________
mpls-tp mailing list
mpls-tp <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp



_______________________________________________
mpls-tp mailing list
mpls-tp <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Comments regarding draft-ietf-mpls-tp-fault-04.txt

Hi all,

I have some comments concerning the I-D on Fault Management for MPLS-TP

Editorial comments:
1. In section 1:  Change "When a disruption occurs on any link or node
along the path of such a transport circuit, OAM are generated ..." to
read "OAM indications are generated" (Note: OAM is a class of
functionality and I don't think that they are generated, either OAM
messages or indications could be generated)

2.In section 2.1.1 third paragraph: "...the LDI flag may be ignored."
Shouldn't this be a normative MAY? (considering that in the next
sentence you use a normative SHOULD)

3.Section 2.2: "...has been administratively locked to communicated that
condition ..." Not sure what the intention was - either change
/communicated/communication,/ or change /locked to communicated/locked,
to communicate/

4.Section 3: change "The FM Channel does not use ACH TLVs and MUST
not..." to "and MUST NOT ..."

5.Section 5.3 change "to ensure that that" to "to ensure that"

6. Section 6: change "are optional to implement" to "are OPTIONAL to
implement"

7. Section 8.1: change "0xHHHH" to "0xHH" to align with the other
occurrences (even though this will eventually be changed by the RFC
Editor)

Questions for clarification:
1.  In section 2 it states that "The messages are sent to the client
MEPs by inserting them in the affected LSPs in the direction opposite to
the detecting MEP's peer server MEP(s)."  While I know that this has
been discussed between the IETF and the ITU-T, I am not sure that I
understand how the client MIP that is actually sending the OAM message
knows which direction is "opposite to the detecting..." is there some
indication that is included in the indication (or is this out-of-scope
to this I-D and part of some external document?).

2. Section 2.1.1 It is unclear to me from reading this section when you
are referring to protection switching at the Server layer and when to
protection/recovery at the Client level.  For example, in reference to
the LDI flag you state - "However if the protection switch was
unsuccessful in restoring the link ..., the LDI flag MUST be set." Which
level is performing the protection switch that was unsuccessful?
Earlier (at the end of Section 2.1) you state that "When the LDI is set,
... to trigger recovery mechanisms"  is this at the Client layer?  Later
you speak of the LDI flag being dependent upon whether the Server layer
is protected or not.

3. Section 4.1.1-3 deal with the encoding of different identifier TLVs -
wouldn't it be safer to just reference the mpls-tp-identifiers draft?
In light of the recent discussion shouldn't section 4.1.3 be clarified
regarding the use of Country Codes in the Global ICC?

4. Section 5.2 states that "Other fields of the FM message SHOULD NOT be
modified." Yet in section 5.3 it states that a FM message with the
R-flag set is ignored if the Msg Type field and Interface Identifier TLV
do not match an existing condition.  In light of this, shouldn't it be
stated that these two fields SHALL NOT be modified?  Also shouldn't
there be more normative text in the second paragraph of section 5.3?

Thanx and Best regards,
Yaacov

-----Original Message-----
From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
ext Internet-Drafts <at> ietf.org
Sent: Thursday, May 05, 2011 9:30 PM
To: i-d-announce <at> ietf.org
Cc: mpls <at> ietf.org
Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-fault-04.txt

A new Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiprotocol Label Switching Working
Group of the IETF.

    Title         : MPLS Fault Management OAM
    Author(s)     : G. Swallow, et al
    Filename      : draft-ietf-mpls-tp-fault-04.txt
    Pages         : 15
    Date          : 2011-04-26

   This draft specifies OAM messages to indicate service disruptive
   conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths
   (LSPs).  The notification mechanism employs a generic method for a
   service disruptive condition to be communicated to a Maintenance End
   Point (MEP).  An MPLS Operation, Administration, and Maintenance
   (OAM) channel is defined along with messages to communicate various
   types of service disruptive conditions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Loa Andersson | 4 Jul 09:01 2011
Picon

Closed: Re: working group last call on draft-ietf-mpls-tp-mib-management-overview-04.txt

All,

this working group last call is closed.

There has been comments, can the authors please update the
draft and republish it.

/Loa
  for the mpls wg chairs

On 2011-06-16 09:48, Loa Andersson wrote:
> Working Group,
>
> this is to start a two week working group last call on
> draft-ietf-mpls-tp-mib-management-overview-04.txt
>
> Please send your comments to the mpls <at> ietf.org mailing list.
>
> This working group last call ends on June 30th 2011.
>
>
> /Loa
>
> for the mpls wg co-chairs

--

-- 

Loa Andersson                         email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager            loa <at> pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Stewart Bryant | 4 Jul 13:30 2011
Picon

Re: ICC and CC

I have been away for a few days and so have only just had time to read the thread. Here is what I posted to the ITU list:

I pulled up a copy of Y.1731-2008

Y.1731-2008 defines MEG ID type 32

It says length MUST be 13

It says MEG ID MUST be 7 to 12 characters

It says that everything that follows the last alpha/numeric MUST be a NULL.

An implementation can expect that this definition of type 32 is definitive and that any thing else is an error.

It is impossible to do an exhaustive investigation of all existing implementations and implementations in progress. Thus to change the definition of type 32 is unsafe.

Therefore the only safe way to introduce an ICC that contains a country code is to define a new MEG ID type.

A new MEG ID type  is not constrained by the definition of type 32.

- Stewart (no hats on)



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Huub van Helvoort | 4 Jul 13:57 2011
Picon

Re: ICC and CC

Hello Stewart,

You wrote:

> I have been away for a few days and so have only just had time to
 > read the thread.

(Maybe you skipped a few messages)

The request from George was for the definition of a global
unique ICC for *MPLS-TP*.
The answer is:
To make it globally unique use the format: [ICC]/[CC]
where [ICC] is the 1-6 character ITU-T Carrier Code,
and [CC] is the 2 character ISO Country Code.

> Here is what I posted to the ITU list:
>
> I pulled up a copy of Y.1731-2008

This addresses Y.1731 and is not relevant to the question
from George.

Regards, Huub.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls


Gmane