Re: [CCAMP] 答复: 答复: 答复: 答复: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

["Margaria, Cyril (NSN - DE/Munich)" <[e-mail]>]

 

Hi, 

 

My understanding of the hybrid node is the following : the ports #b and #c are TDM ports , port #b terminate the VC4 trail and provide a PSC Access point.

 

The example I shown is a node with a PXC . port #e in TDM is a colored OTU3 port, so I would be interested to know what makes you think the example choosen is

not OTN equipment? The physical link does not support both switching, but the GMPLS link interface can, as explained in RFC4397 section 3.6.2, this can mix the trail termination and adaptation and server layer connection point, which is exactly the concept illustrated in RFC5339 and my example.

 

I could also take the Figure 3 of draft-ietf-ccamp-rwa-info-12, internal port 1 2 3 4 of the ROADM can be connected internal to an OTU3 -> ODU3 -> ODU2 -> OTU2 ports, 

Using RFC6001 is possible but not mandatory, the new solution should also work with and without support of RFC6001 (or mandate support of RFC6001) 

 

I am still missing rules on how to interpret the label format in the examples I provided, It would be equally interesting to add the third example you mentioned (with IACD) 

 

The examples I mentioned come for existing node architecture where the general constraints are very useful, but some points still  remains to be clarified.

 

That said, there is several potential solution that could be considered and be generic : 

-          Explicitly scope the labels by having (switching type, encoding)  for port label restriction, available labels, shared labels, a corresponding ISCD or IACD MUST be present

-        Only allow one ISCD (It will be a big restriction) and extend IACD (maybe using Adjustment Capability-specific information ) 
-     ?

 

BR 

Cyril

 

 

From: ext Zhangfatai [mailto:[e-mail]] 
Sent: Friday, September 30, 2011 4:44 AM
To: Margaria, Cyril (NSN - DE/Munich); [e-mail]
Subject: 答复: 答复: 答复: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

 

Hi Cyril,

 

Interesting example. The hbrid example in RFC5339 is TDM+PSC (that is coming to us), instead of TDM+DWDM (I think your example is not OTN equipment), :-)

 

In your example, for the TE link 5, it will/could advertise WSON links +IACD based on RFC6001(In this way, there is still implicit relationship between ISCDs and label sub-TLVs).

Certaintly, I think there is still lofs of work to be done for MLN control because RFC6001 is not sufficient.

 

Anyway, your example is appreciated.

 

 

Thanks

 

Fatai

 

 

 

________________________________

发件人: Margaria, Cyril (NSN - DE/Munich) [[e-mail]]
发送时间: 2011年9月29日 19:05
到: Zhangfatai; [e-mail]
主题: RE: 答复: 答复: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi Fatai, 

 

For my example I took the example from RFC5339 (also following the logic of RFC4202 section 2.4.6), adjusting the capabilities and extended the number of ports:

 

                             Network element

                        .............................

                        :            --------       :

              TDM       :           |  TDM   |      :

            Port1-------------<->---|#a      |      :

            Port2-------------<->---|#b      |      :

            Port3-------------<->---|#c      |      :

            Port4-------------<->---|#d      |      :

                        :  +--<->---|#e      |      :

                        :  |         --------       :

                        :  |        ----------      :

              DWDM      :  +--<->--|#f  DWDM  |     :

            Port5 ------------<->--|#g        |     :

                        :           ----------      :

                        :............................

 

                           Figure 1a.  Hybrid node.

 

From ISCD point of view:

TE link 1 (Port1):

     - ISCD sub-TLV: TDM  (ODU2) 

TE link 2 (Port1):

     - ISCD sub-TLV: TDM  (ODU2) 

…

TE-Link 5 (port 2) : 

     - ISCD #1 sub-TLV: DWDM 

     - ISCD #2 sub-TLV: TDM, G.709 ODUk (ODU3) 

 

The ISCD #2 represent the DWDM-TDM adjustement capability

I am leaving out in this thread how to know the OEO capability of port #f/#e ;-)

 

 

With the following connectivity matrix (with the following convention : ({Link Set A#1},{Link set B#1}),({Link Set A#2},{Link set B#2}),…

 

Matrix #1 ({Port 1}, {Port 5}) 

Matrix #2 ({Port 2}, {Port 5})

Matrix #3 ({Port 3}, {Port 5})

Matrix #4 ({Port 4}, {Port 5})

 

TE-Link 5 (port 2) : 

     - ISCD #1 sub-TLV: DWDM 

     - ISCD #2 sub-TLV: TDM, G.709 ODUk (here ODU3, because of the port #e)

     - Port Label restriction : Matrix #1, RestrictionType=SIMPLE_LABEL, Label = TS :16,12,8,4 (can we be sure of the interpretation ?)

     - Port Label restriction : Matrix #2, RestrictionType=SIMPLE_LABEL, Label = TS :15,11,7,3

     - Port Label restriction : Matrix #3, RestrictionType=SIMPLE_LABEL, Label = TS :14,10,6,2

     - Port Label restriction : Matrix #3, RestrictionType=SIMPLE_LABEL, Label = TS :13,09,5,1

I am not 100% sure that we can always interpret the label as ODU label, RFC4202 section 2.4.7 on how to interpret the

Label on a TE-Link would indicate that if one end support TDM and the other LSC, the label should represent a lambda, 

but the case where there is several ISCD is not well described.

 

The draft should detail the rules on which label encoding to use in case of connectivity matrix in that case.

 

In that example we have fixed MUX ODU3->ODU2 AND each ODU2 is assigned to an port: the port label restriction is used, 

Rules for port label restriction should allow to interpret correctly the label.

 

However on case of Fixes MUX and flexible ODU2 to port assignment one allowed possibility is the following : 

Matrix #11 ({Port 1, Port 2, Port 3, Port 4,}, {Port 5})

 

TE-Link 5 (port 2) : 

     - ISCD #1 sub-TLV: DWDM 

     - ISCD #2 sub-TLV: TDM, G.709 ODUk (ODU3) 

    - Available  Labels : « TS :15,11,7,3 », « TS :14,10,6,2 », « TS :13,09,5,1 », « TS :16,12,8,4”

     - Available  Labels : channels (DWDM) 

 

How to make sure the interpretation is correct, This is an typical case covered by the generic GMPLS RFCs, so 

 It should  be covered in my opinion by the generic extensions.

 

 

 

 

 

From: ext Zhangfatai [mailto:[e-mail]] 
Sent: Thursday, September 29, 2011 12:19 PM
To: Margaria, Cyril (NSN - DE/Munich); [e-mail]
Subject: 答复: 答复: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

 

Hi Cyril,

 

Usually, one TE link advertisement (with serveral ISCDs and multiple label sub-TLVs) has the same Switching Capability, so there is implicit relationship between the ISCDs and label sub-TLVs.

 

I would like to consider your last point when I udpate this draft in the next version. 

 

But I have a question on your example, do you see that there is a line port (or interface) can support both DWDM and TDM in the world? I think if a line port can support DWDM, the WSON TE link (with WSON related label (wavelength) information) should be advertised for this line port; if a line port can support TDM, then the TDM TE link (e.g., ODU) for this line port should be advertised. Even though there was one port could support both DWDM and TDM, I think usually it should advertise these two types of capability separately, ie., use seperate TE link advertisements. so, I think there is implicit relationship between the ISCDs and label sub-TLVs.

 

Even though I think we should not use a kind of special and complex example to explain something, I will bear your example in my mind when I update the draft (as I said in the second sentence above).

 

Thanks

 

Fatai

 

 

________________________________

发件人: Margaria, Cyril (NSN - DE/Munich) [[e-mail]]
发送时间: 2011年9月29日 17:36
到: Zhangfatai; [e-mail]
主题: RE: 答复: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi, 

 

If I understand correctly, you state that there is not explicit or implicit relationship between the ISCD and label sub-TLV, correct?

I would expect a new generic draft to be applicable to all already defined label format, so  it seems missing in the document.

 

Could you consider my last point regarding the example of switching restriction in G.709 v2 and DWDM context, it would be helpful 

 to have some statement even though it will not be in the document.

 

Best Regards.

 

 

From: ext Zhangfatai [mailto:[e-mail]] 
Sent: Wednesday, September 28, 2011 4:30 AM
To: Margaria, Cyril (NSN - DE/Munich); [e-mail]
Subject: 答复: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

 

Hi Cyril,

 

I agree on your first suggestion.

 

Secondly, this draft is generic, when it needs to advertise label information for some specific tech (e.g., TDM), the document about specific tech can refer to this draft and should define how to correlate the ISCDs and label sub-TLVs if there is no explicit or implicit relationship between them (I think there are lots of potential solutions to handle that, it is quite tech specific stuff). 

 

 

Fatai

 

Thanks

 

 

________________________________

发件人: Margaria, Cyril (NSN - DE/Munich) [[e-mail]]
发送时间: 2011年9月27日 17:38
到: Zhangfatai; [e-mail]
主题: RE: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi, 

 

Thanks for the answer, 

 

Please see inline

 

 

From: ext Zhangfatai [mailto:[e-mail]] 
Sent: Tuesday, September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - DE/Munich); [e-mail]
Subject: 答复: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

 

Hi Cyril,

Thanks for your commets.

Please see in-line below.


Fatai

Thanks



________________________________________
发件人: Margaria, Cyril (NSN - DE/Munich) [[e-mail]]
发送时间: 2011年9月26日 16:03
到: Zhangfatai; [e-mail]
主题: RE: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,

I have the following comments/question regarding this revision

3.2. Available Labels:

The text state : “The Available Labels sub-TLV   may occur at most once within the link TLV.”

How to encode different label format in that case? I think the label format would depend
on the ISCD, and as we might have several ISCD, having several Available Label sub-TLV make sense.
This also apply to 3.3. Shared Backup Labels.

[Fatai] This "may" should be "MAY" according to Lou's suggestion, so it does not prevent you to have several available label sub-TLVs. 

[Cyril] Stating “The Available Labels sub-TLV   MAY  occur more than once within the link TLV.”  Would be more accurate and easier to understand.

 


In case of several ISCD are present for a given advertisement how to interpret the label format in the
label-related sub-TLVs?


[Fatai] It is easy to achive that. e.g, in SDH network, a node can advertise several ISCDs with one or multiple label sub-TLVs (I assume "IF" label information is needed to be advertised here), why it cannot interpret the labels are SDH labels?

[Cyril]  If there is 2 ISCD sub-TLV and 2 available label sub-TLV, how to tell which available label sub-TLV relate to which ISCD sub-TLV?

 


Could you clarify this point, it would be useful for instance to consider the example of a link supporting SDH
(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 v3 label format).

 

[Fatai]  Do you mean to have an example on hybrid node? I will not use a complex example to explain a kind of simple thing (It will confuse people). 

[Cyril] It may not be so simple, I have trouble to interpret label without knowing the ISCD considered and I do not see clearly the relation between the two in the document.


The text is very focused on WSON, while it is a very interesting example, having other technology (OTN for
example would help to show that the solution is generic.

[Fatai] I think one typical example is sufficient for people to understand things. TDM network is different from WSON network. In TDM network, usually it will not advertise label information even though label information could be advertised.

[Cyril] They are indeed different, but from label point of view it should not make a difference. A usual use case of connectivity matrix would be for example on client cards with switching restriction : fixed Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for instance)  on DWDM node :

the restriction can be modeled as one connectivity matrix per client port,

        the client port have then ISCD TDM, 

        the other ports can do DWDM and TDM, 

        for the connectivity matrix corresponding to a client port the only ODU label to be assigned (due to fixed MUX) is specified 

 

First, is this modeling correct? 

Second, how to make sure the label restriction are to be interpreted as ODU labels?

 

I think it is also important to show that the extensions are also working outside the framework they were born (WSON).

 

BR



Best Regards,
Cyril

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of ext Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> To: [e-mail]
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> A new version has been submitted to address the comments from the WG
> discussion.
>
> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new
> section (Section 5) was added to describe scalability issue.
>
> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> general-constraints-ospf-te-02.txt
>
> Please check out for details and comments are always welcome.
>
>
> Thanks
>
> Fatai
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: 2011年9月22日 17:06
> To: [e-mail]
> Cc: [e-mail]
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Common Control and
> Measurement Plane Working Group of the IETF.
>
>       Title           : OSPF-TE Extensions for General Network Element
> Constraints
>       Author(s)       : Fatai Zhang
>                           Young Lee
>                           Jianrui Han
>                           Greg Bernstein
>                           Yunbin Xu
>       Filename        : draft-ietf-ccamp-gmpls-general-constraints-
> ospf-te-02.txt
>       Pages           : 14
>       Date            : 2011-09-22
>
>    Generalized Multiprotocol Label Switching can be used to control a
>    wide variety of technologies including packet switching (e.g.,
> MPLS),
>    time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
>    spatial switching (e.g., incoming port or fiber to outgoing port or
>    fiber). In some of these technologies network elements and links may
>    impose additional routing constraints such as asymmetric switch
>    connectivity, non-local label assignment, and label range
> limitations
>    on links. This document describes OSPF routing protocol extensions
> to
>    support these kinds of constraints under the control of Generalized
>    MPLS (GMPLS).
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp