headers
Yaakov Stein | 1 Jul 2007 07:21
Favicon

RE: [PWE3] New Liaison Statement, "Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1"

Neil, 

Yes, I quite agree that there can be client-server relationships (either
way).

What I want is a clear statement that there can be no peer relationship.

Sasha's comment on separate Ethertypes is, of course, a good solution,
but we need to state the requirement first and then give this as one
possible solution.
BTW, we have requested this several times already.

BTW

-----Original Message-----
From: neil.2.harrison <at> bt.com [mailto:neil.2.harrison <at> bt.com] 
Sent: Thursday, June 28, 2007 09:27
To: Yaakov Stein
Cc: stbryant <at> cisco.com
Subject: RE: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS WG
concerns with G.8110.1 Amendment 1"

Hi Yaakov,

Good point...a key corollary of which IMO is that T-MPLS cannot be
claimed to be a sub-set of MPLS.....so one could call T-MPLS anything
one likes now....indeed, perhaps IETF should request this of ITU to
avoid any confusion?

However, whilst I accept there should be no attempt at interworking MPLS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yaakov Stein | 1 Jul 2007 07:28
Favicon

RE: RE: [PWE3] New Liaison Statement, "Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1"

Phil, 

There are several types of interworking.

"Nework interworking" or "client-server" interworking means carrying one
network layer over another. See all the ITU Y.14xx Recommendations for
further explanations.

"Service interworking" or "peer to peer interworking" means passing the
payload information
between two different network technologies.

The documents being presented claim that T-MPLS is a different network
technology
from IETF-defined MPLS (or what they call IP-MPLS). Different needn't
mean incompatible
formats, it is enough for one to be a strict subset of the other (e.g
disallow certain
features). In this case interworking (of one type or the other) needs to
be defined.
Those proposing T-MPLS are claiming that interworking need not be
defined
as they assume that there are no use cases for this. (I disagree)

Y(J)S

-----Original Message-----
From: Phil Bedard [mailto:bedard.phil <at> gmail.com] 
Sent: Friday, June 29, 2007 22:21
To: Sasha Vainshtein
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyung-Yeop Hong (hongk | 2 Jul 2007 17:00
Picon
Favicon

RE: RE: [PWE3] New Liaison Statement, "Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1"

Yaakov, Phil, Stewart et al,

In the Scope section of the previously approved G.8110.1 (T-MPLS
architecture), it was stated:
"Further a T-MPLS network will not peer directly with an IP/MPLS
network".
(I think this implies that T-MPLS does not support service interworking
with IP/MPLS)

At the last Q12/15 meeting, they modified the above sentence in the
Scope section as follows:
"Further a T-MPLS network will have a client/server relationship with an
IP/MPLS network".
(I think this implies that T-MPLS may support network interworking with
IP/MPLS, although I am not sure about what "will" means in the context
of Rec)

Those proposing T-MPLS proposed "IP/MPLS and T-MPLS Interoperability" at
the last meeting and following is the meeting report FYI:
"Contribution C595, (Alcatel-Lucent), "IP/MPLS and T-MPLS
Interoperability" raised some concerns.  It was noted that we have
agreed that we do not expect IP/MPLS and T-MPLS to directly
interoperate.  It was clarified that the contributions addresses use of
a Pseudowire that spans a MPLS and a T-MPLS network.  I was noted that
Q7/13 has responsibility for PW interworking.  It was suggested that the
intent was that the T-MPLS network would encapsulate the MPLS PW.
Further clarification of the network application is required before any
action can be taken."

It seems like the intent was the network interworking, but then Q7/13
(Continue reading)

Permalink | Reply | 0 comments |
headers
MAHESH PORWAL | 4 Jul 2007 08:50
Picon
Favicon

i want to join this

i want to join this

      ____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us.
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Jul 2007 20:15
Picon
Favicon

I-D ACTION:draft-ietf-mpls-multicast-encaps-06.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 Multicast Encapsulations
	Author(s)	: T. Eckert, et al.
	Filename	: draft-ietf-mpls-multicast-encaps-06.txt
	Pages		: 10
	Date		: 2007-7-5
	
RFC 3032 established two data link layer codepoints for MPLS: one to
   indicate that the data link layer frame is carrying an MPLS unicast
   packet, and the other to indicate that the data link layer frame is
   carrying an MPLS multicast packet.  This specification updates RFC
   3032 by redefining the meaning of these two codepoints.  The former
   "multicast codepoint" is now to be used only on multiaccess media,
   and it is to mean "the top label of the following label stack is an
   upstream-assigned label".  The former "unicast codepoint" is to be

   used in all other cases.  Whether the data link layer payload is a
   unicast MPLS packet or a multicast MPLS packet is now to be
   determined by looking up the top label, rather than by the codepoint.

   RFC 3032 does not specify the destination address to be placed in the
   "MAC DA" field of an ethernet frame which carries an MPLS multicast
   packet.  This document provides that specification.

   This document updates RFC 3032 and RFC 4023.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
chenxb | 6 Jul 2007 03:05
Picon

I have two question about the Generalized PWid FEC Element in RFC4762 。


Hi all,

I have two question about the Generalized PWid FEC Element in RFC4762。

The first question:
       
Section 6.1.1 in  RFC 4762 say:
   Target Attachment Individual Identifier (TAII), Source Attachment    
   Individual Identifier (SAII): These are null because the mesh of PWs  
   in a VPLS terminates on MAC learning tables, rather than on
   individual attachment circuits.  The use of non-null TAII and SAII is
   reserved for future enhancements.
 

My question is ,
what dose this statement mean?
whether means that TAII and SAII is not present or
means that TAII and SAII is present but Length field value is zero?
if it's the latter, what's the  TAII and SAII Type field value?
if it's the former, it seems to conflict with RFC 4447 section 5.3.2.
because in RFC 4447 secion 5.3.2 say,
   If a particular application does not need all three of these sub-elements, it MUST
   send all the sub-elements but set the length to 0 for the unused
   sub-elements.


The second question:
Section 6.1.1 in  RFC 4762 say:
   Attachment Group Identifier (AGI), Length, Value: The unique name of
   this VPLS.  The AGI identifies a type of name, and Length denotes the
   length of Value, which is the name of the VPLS.  We use the term AGI
   interchangeably with VPLS identifier.

My question is,
what's the AGI Type filed value that indicated the AGI value is VPLS name?


Thanks and Regards
Jerry king
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Neil Thomson | 6 Jul 2007 18:57
Favicon

Neil Thomson/GIS/CSC is out of the office.


I will be out of the office starting  06/07/2007 and will not return until
17/07/2007.

For local urgent enquiries please contact David Brewer CSC (0141 957 2589).

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Adrian Farrel | 7 Jul 2007 22:07
Picon

Re: Early MIB Dr. review of draft-ietf-mpls-p2mp-te-mib-03.txt

Thanks Joan,

 A new revision to address most of your points has just been submitted.

But a couple of items are discussed below.

You asked:

>> *) Are there any objects which apply only to GMPLS?

There is no difference (at this time) between P2MP MPLS-TE  and P2MP GMPLS. 
All objects can be applied to GMPLS.

>> **) 6.1. Example Use of the LSR MIB Module
>>
>> Even if the LSR MIB is able to be used to configure P2MP,
>> SHOULD it be used?
>> What is the benefit of doing so?
>> Are networks really doing this?
>>
>> My concern is that it is far easier to document one way of configuring a 
>> feature and supporting this way through the standards process than to
>> put forth a secondary way to configure.  So unless there is truly a 
>> compelling reason, why do this?
>>
>> If you want to proceed with the LSR MIB being used for p2mp,
>> then you need to show an example of how to configure this.  Order
>> of the configuration seems critical, and that needs to be explained.

You'll notice that RFC3813 allows write access to the LSR MIB.
So, clearly it was deemed acceptable to manually set up forwarding state (or 
cross-connections). And we must recall that (much as I love the control 
plane) the control plane is not the only way to operate a network. Consider, 
for example, the majority of transport networks.

Now, you'll also note that RFC3813 allows a "cross-connect" to have multiple 
in and out segments.

So I don't think there is anything else to say.

>> *)    mplsTeP2mpTunnelNotificationEnable OBJECT-TYPE
>>
>> Can RFC3413 be used instead?

Do you feel strongly about this?
We could use it, but:
- we should probably follow the same structure as RFC3812
- I don't like forcing the support of another MIB module for this
   one bit (literally) of information.

>> * Why is RFC4461 in the informative section?  Would think this should
>> be in the Normative.

The downref rules are a pain :-) and it is easier to avoid them than deal 
with them.

> Section "4.2 Use of MPLS-TE-STD-MIB".
>
> There was concern that using the same Objects with updates from
> MPLS-TE-STD-MIB would result in a backwards compatibility
> issue.  (If the situation came about that there were devices that 
> supported
> the original version of the MPLS-TE-STD-MIB and a newer version, then
> the interpretation of these objects might be confused.
> The suggestion was to create new objects in this MIB.
> Also, it would be necessary to include in the conformance section
> of the MIB what objects from MPLS-TE-STD-MIB need to
> be supported.

I don't see any backward compatibility issues.
Legacy implementations do not support the P2MP MIB module, so do not have a 
problem.
The functional change is to interpret certain objects in MPLS-TE-STD-MIB 
differently if (and only if) there is a corresponding row entry in 
mplsTeP2mpTunnelTable.

If we created new objects in MPLS-TE-P2MP-STD-MIB (which we could) then we 
would still need to change the interpretation of the objects in 
MPLS-TE-STD-MIB because they would cease to be meaningful. Having decided 
that we had to change the interpretation, we decided that we would not also 
need new objects.

What do you think?

Once again, many thanks.

Adrian 

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 4 comments |
headers
chenxb | 9 Jul 2007 05:11
Picon

One question about Spoke Connectivity for Non-Bridging Devices in RFC4762 。


Hi all,

 Section 10.1.3 in RFC4762 say,
   Note that in the case where PE-r devices use Provider VLANs (P-VLAN)
   as demultiplexers instead of PWs, PE1-rs can treat them as such and
   map these "circuits" into a VPLS domain to provide bridging support
   between them.

I can not unstand this statement ,Could you for example?
i think PE-r devices should use PW labels as demultiplexers more often.

Thanks and Regards
Jerry king
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Nitin Bahadur | 9 Jul 2007 20:08
Favicon

New draft for performing lsp-traceroute for tunneled/stitched LSPs.


Hi,

 A new draft has been submitted... 

http://tools.ietf.org/wg/mpls/draft-nitinb-lsp-ping-over-mpls-tunnel-00.
txt

The draft describes methods for performing lsp-ping traceroute over mpls
tunnels.  The techniques outlined in RFC 4379 (LSP-Ping) fail to perform
correct traceroute validation and path discovery for a LSP that goes
over other mpls tunnels or over stitched LSPs. The draft describes new
procedures that can be used in conjunction with the standard procedures
described in RFC 4379 to trace such LSPs.

It would be great if the WG could go over the draft and provide comments
on the same.

Thanks
Nitin

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 2 comments |

Gmane