headers
Internet-Drafts | 2 Feb 2009 23:15
Picon
Favicon

I-D ACTION:draft-ietf-pwe3-fc-flow-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.

	Title		: Reliable Fibre Channel Transport Over MPLS Networks
	Author(s)	: M. Roth, R. Solomon, M. Tsurusawa
	Filename	: draft-ietf-pwe3-fc-flow-00.txt
	Pages		: 30
	Date		: 2009-1-15
	
   A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames 
   over an MPLS network. This enables service providers to offer 
   "emulated" Fibre Channel services over existing MPLS networks. This 
   document specifies the mechanisms controlling the reliable transport 
   of Fibre Channel PW over MPLS networks. The encapsulation of Fibre 
   Channel PDUs within a pseudowire and the procedures for using a PW to 
   provide a Fibre Channel service are specified in [FC-encap]. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-flow-00.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.
Attachment (draft-ietf-pwe3-fc-flow-00.txt): message/external-body, 68 bytes
(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Luca Martini
 | 
4 Feb 2009 18:10






Picon

Favicon





Re: Comment of draft-ietf-pwe3-ldp-aii-reachability-00


Jin,
Comments below.

Jin, Lizhong (NSN - CN/Shanghai) wrote:
> Hi Simon and all:
> I read the draft-ietf-pwe3-ldp-aii-reachability-00, and have following 
> comments.
> Because LDP does not have the capability of path selection, which is 
> quite different with OSPF and BGP. So some problem will met when using 
> LDP to distribute AII reachability information. Although it has been 
> stated in the draft that: this document does not define a routing 
> protocol, but we also need to consider the following scenario.
> Section 4.1.2, line 381:
> "It MAY also re-advertise those addresses using any another supported 
> dynamic MS-PW routing mechanism."
> Does "dynamic MS-PW routing mechanism" also include LDP capability 
> described in this draft or not? If it does not include, then that 
> means only one LDP session can be supported. If it does include, the 
> S-PE will also re-advertise the AII information to next T-LDP 
> neighbor, and will course the following problem.
> If an S-PE receiving a address list TLV contain one AII address, S-PE 
> has already this L2 PW forwarding entry but with different nexthop, 
> what S-PE's behavior in this situation?
> -------
> --|S-PE2|--
> / ------- \
> /------/ \------\
> ------- ------- ------- -------
> |T-PE1|------|S-PE1| |S-PE3|------|T-PE2|
> ------- ------- ------- -------

(Continue reading)






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


Internet-Drafts
 | 
4 Feb 2009 23:45






Picon

Favicon





I-D Action:draft-ietf-pwe3-segmented-pw-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.

	Title           : Segmented Pseudo Wire
	Author(s)       : L. Martini, et al.
	Filename        : draft-ietf-pwe3-segmented-pw-10.txt
	Pages           : 42
	Date            : 2009-02-04

This document describes how to connect pseudowires (PW) between two
distinct PW control planes or PSN domains. The PW control planes may
belong to independent autonomous systems, or the PSN technology is
heterogeneous, or a PW might need to be aggregated at a specific PSN
point. The PW packet data units are simply switched from one PW to
another without changing the PW payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw-10.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.



Attachment (draft-ietf-pwe3-segmented-pw-10.txt): message/external-body, 70 bytes


_______________________________________________
pwe3 mailing list

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Jin, Lizhong (NSN - CN/Shanghai
 | 
5 Feb 2009 02:54





Re: Comment of draft-ietf-pwe3-ldp-aii-reachability-00


Hi Luca:
I get your meaning. Thank your very much.

Best Regards
Lizhong Jin

-----Original Message-----
From: ext Luca Martini [mailto:lmartini <at> cisco.com] 
Sent: Thursday, February 05, 2009 1:11
To: Jin, Lizhong (NSN - CN/Shanghai)
Cc: sdelord <at> uecomm.com.au; frederic.jounay <at> orange-ftgroup.com;
philippe.niger <at> orange-ftgroup.com; mustapha.aissaoui <at> alcatel-lucent.com;
matthew.bocci <at> alcatel-lucent.co.uk; yaakov_s <at> rad.com;
caowayne <at> huawei.com; PWE3 WG (E-mail)
Subject: Re: [PWE3] Comment of draft-ietf-pwe3-ldp-aii-reachability-00

Jin,
Comments below.

Jin, Lizhong (NSN - CN/Shanghai) wrote:
> Hi Simon and all:
> I read the draft-ietf-pwe3-ldp-aii-reachability-00, and have following

> comments.
> Because LDP does not have the capability of path selection, which is 
> quite different with OSPF and BGP. So some problem will met when using

> LDP to distribute AII reachability information. Although it has been 
> stated in the draft that: this document does not define a routing 
> protocol, but we also need to consider the following scenario.

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


frederic.jounay
 | 
6 Feb 2009 09:37





Re: Comment of draft-ietf-pwe3-ldp-aii-reachability-00


Lizhong, Luca,

Please find hereafter the changes proposed to clarify the point

An S-PE receiving an address list TLV containing one or more AII addresses should install those addresses
in its local PW routing table. It MAY also re-advertise those addresses using any another supported
dynamic MS-PW routing mechanism.
=>  
An S-PE receiving an address list TLV containing one or more AII addresses should install those addresses
in its local PW routing table. It MAY also re-advertise those addresses using any another supported
dynamic MS-PW routing protocol like BGP [BGP AD] or OSPF [OSPF MS-PW]. An S-PE cannot send the attached
T-PE address to other S-PE using T-LDP , because it is not a local connected address. The only routes that an
S-PE MAY redistribute using T-LDP is connected (local) routes and a "default" route as an exception. 

Let me know if this is still confusing, if not I 'll update the draft.

thanks,
Fred 

-----Message d'origine-----
De : Luca Martini [mailto:lmartini <at> cisco.com] 
Envoyé : mercredi 4 février 2009 18:11
À : Jin, Lizhong (NSN - CN/Shanghai)
Cc : sdelord <at> uecomm.com.au; JOUNAY Frederic RD-RESA-LAN; NIGER Philippe RD-RESA-LAN;
mustapha.aissaoui <at> alcatel-lucent.com; matthew.bocci <at> alcatel-lucent.co.uk; yaakov_s <at> rad.com;
caowayne <at> huawei.com; PWE3 WG (E-mail)
Objet : Re: [PWE3] Comment of draft-ietf-pwe3-ldp-aii-reachability-00

Jin,
Comments below.

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Jin, Lizhong (NSN - CN/Shanghai
 | 
6 Feb 2009 09:48





Re: Comment of draft-ietf-pwe3-ldp-aii-reachability-00


Hi Fred:
The change is clear now, thank you.

Best Regards
Lizhong Jin

-----Original Message-----
From: ext frederic.jounay <at> orange-ftgroup.com [mailto:frederic.jounay <at> orange-ftgroup.com] 
Sent: Friday, February 06, 2009 16:38
To: lmartini <at> cisco.com; Jin, Lizhong (NSN - CN/Shanghai)
Cc: sdelord <at> uecomm.com.au; philippe.niger <at> orange-ftgroup.com;
mustapha.aissaoui <at> alcatel-lucent.com; matthew.bocci <at> alcatel-lucent.co.uk; yaakov_s <at> rad.com;
caowayne <at> huawei.com; pwe3 <at> ietf.org
Subject: RE: [PWE3] Comment of draft-ietf-pwe3-ldp-aii-reachability-00

Lizhong, Luca,

Please find hereafter the changes proposed to clarify the point

An S-PE receiving an address list TLV containing one or more AII addresses should install those addresses
in its local PW routing table. It MAY also re-advertise those addresses using any another supported
dynamic MS-PW routing mechanism.
=>  
An S-PE receiving an address list TLV containing one or more AII addresses should install those addresses
in its local PW routing table. It MAY also re-advertise those addresses using any another supported
dynamic MS-PW routing protocol like BGP [BGP AD] or OSPF [OSPF MS-PW]. An S-PE cannot send the attached
T-PE address to other S-PE using T-LDP , because it is not a local connected address. The only routes that an
S-PE MAY redistribute using T-LDP is connected (local) routes and a "default" route as an exception. 

Let me know if this is still confusing, if not I 'll update the draft.

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Mahesh Singh C
 | 
6 Feb 2009 10:17






Picon

Favicon





Need clarification on 5086 RFC - Section 5.3










Hi Sasha,



 



 I would like to understand the below recommendation in
RFC 5086 better.



 



Section 5.3 Extending Basic NxDS0 Services
with CE Application Signaling



 



 “Signaling packets SHOULD be
carried in a separate dedicated PW.



 However, implementations MAY carry them in the same PW as the TDM



 data packets for the basic NxDS0 service.  The methods of
"pairing"



 the PWs carrying TDM data and signaling packets for the same
extended



 NxDS0 service are out of scope of this document.”



 



The first statement specifies SHOULD. From my understanding, if we try
to implement as per the next statement the meaning of first statement is
becoming false right? 



 



Is it mandatory to send signaling packets in separate PW and data
packets in another separate PW?



 



OR 



 



Can we send signaling packets and data packets in the same PW. The
required information in the same PW packets can be distinguished using its CW. Can
we implement like this. This I believe as per the second statement above. But,
since the first statement has SHOULD, I am not sure on this approach. 



 



Regards,



Mahesh



 



 






DISCLAIMER:

-----------------------------------------------------------------------------------------------------------------------


The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 

this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 

this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 

received this email in error please delete it and notify the sender immediately. Before opening any mail and 

attachments please check them for viruses and defect.


-----------------------------------------------------------------------------------------------------------------------






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






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Loa Andersson
 | 
6 Feb 2009 11:11






Picon





working group last call on draft-ietf-mpls-tp-requirements-04


All,

this is to initiate a working group last call for 
draft-ietf-mpls-tp-requirements-04.

This document is one of the key documents for the mpls-tp work,
in particular it is important that the ITU-T mpls-tp ad hoc team
verifies the completeness of the requirements and that we have a
good review form all parties.

Please review and send your comments to the mpls-tp list,
i.e. try to avoid doing a "reply all on this message" !

The working group last call will end on Feb 28, 2009.

/Loa

--

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  loa.andersson <at> ericsson.com
                                               loa.andersson <at> redback.com
                                               loa <at> pi.nu






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Ben Niven-Jenkins
 | 
6 Feb 2009 16:20






Favicon





Re: working group last call on draft-ietf-mpls-tp-requirements-04


Colleagues,

In my rush to get this ready for last call I made an editing mistake,
requirement 30 currently reads

   30  MPLS-TP MUST support unidirectional, bidirectional and co-routed
       bidirectional point-to-point transport paths.

But it should read

   30  MPLS-TP MUST support unidirectional, bidirectional and associated
       bidirectional point-to-point transport paths.

This has no impact in terms of the meaning of the requirement, just an
editing error where I updated the terminology section to reflect discussion
on the MPLS-TP mailing list but forgot to subsequently update the
requirement to use the agreed term.

Ben

On 06/02/2009 10:11, "Loa Andersson" <loa <at> pi.nu> wrote:

> All,
> 
> this is to initiate a working group last call for
> draft-ietf-mpls-tp-requirements-04.
> 
> This document is one of the key documents for the mpls-tp work,
> in particular it is important that the ITU-T mpls-tp ad hoc team
> verifies the completeness of the requirements and that we have a
> good review form all parties.
> 
> Please review and send your comments to the mpls-tp list,
> i.e. try to avoid doing a "reply all on this message" !
> 
> The working group last call will end on Feb 28, 2009.
> 
> /Loa






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Alexander Vainshtein
 | 
7 Feb 2009 11:49





Re: Need clarification on 5086 RFC - Section 5.3






Mahesh,


Quoting from RFC 2119 that defines the meaning of key words defining requirement levels:


 


<quote>





SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
...
MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional.  One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)





<end quote>


 


IMHO the wording used in RFC 5086 allows you to carry signaling packets in the same PW with the data packets if you see compelling reasons to do that and fully understand the implications. One of these implications
 is, of course, that your implementation will be non-interoperable with the implementations that carry signaling packets in separate PW.



 


I cannot say at the moment which implementations prevail in the industry today, since CESoPSN applications I actually deal with lately do not require the signaling packets' functionality.


 


Hopefully, these notes will be helpful.


 


 


Regards,


     Sasha


 



From: Mahesh Singh C [maheshsc <at> hcl.in]
Sent: Friday, February 06, 2009 11:17 AM
To: Alexander Vainshtein
Cc: pwe3 <at> ietf.org
Subject: Need clarification on 5086 RFC - Section 5.3











Hi Sasha,


 


 I would like to understand the below recommendation in RFC 5086 better.


 


Section 5.3
Extending Basic NxDS0 Services with CE Application Signaling


 


 “Signaling packets SHOULD be carried in a separate dedicated PW.


 However, implementations MAY carry them in the same PW as the TDM


 data packets for the basic NxDS0 service.  The methods of "pairing"


 the PWs carrying TDM data and signaling packets for the same extended


 NxDS0 service are out of scope of this document.”


 


The first statement specifies SHOULD. From my understanding, if we try to implement as per the next statement the meaning of first statement is becoming false right?



 


Is it mandatory to send signaling packets in separate PW and data packets in another separate PW?


 


OR



 


Can we send signaling packets and data packets in the same PW. The required information in the same PW packets can be distinguished using its CW. Can we implement like this.
 This I believe as per the second statement above. But, since the first statement has SHOULD, I am not sure on this approach.



 


Regards,


Mahesh


 


 





DISCLAIMER:

-----------------------------------------------------------------------------------------------------------------------


The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in


this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of


this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have


received this email in error please delete it and notify the sender immediately. Before opening any mail and


attachments please check them for viruses and defect.


-----------------------------------------------------------------------------------------------------------------------









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






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane