Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,

[Dan Li <[e-mail]>]

Hi Dimitri,

There is nothing wrong with the GR draft, the mechanism described in that draft doesn't need any remedial patch, and it is applied to this draft. The reason we started working on this draft is try to clarify the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered depending on the order in which the nodes restart.

Thanks,

Dan

----- Original Message ----- 
From: <[e-mail]>
To: "Dan Li" <[e-mail]>
Cc: "ccamp" <[e-mail]>; "Olufemi Komolafe" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 27, 2006 12:50 AM
Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,


> hi dan 
> 
> yes i have a very practical issue - the document would then deal with 
> remedial to remedial - ... but do we have any feedback on initial 
> remedials ?
> 
> thanks,
> - d. 
> 
> 
> 
> 
> 
> Dan Li <[e-mail]>
> Sent by: [e-mail]
> 25/09/2006 09:27
>  
>         To:     Olufemi Komolafe <[e-mail]>, [e-mail]
>         cc:     ccamp <[e-mail]>
>         Subject:        Re: Comments on 
> draft-li-ccamp-multinodes-gr-proc-00.txt,
> 
> 
> Hi Femi,
> 
> Thanks for your valuable suggestion! 
> 
> The intention for this draft is clarify the procedures for multi-nodes 
> restart, so five typical scenarios have been listed in the draft, I think 
> most of the failed cases are covered by these five scenarios. As you have 
> pointed out, these scenarios may be raised due to multiple nodes fail, or 
> a subsequent control channel failure. Yes, you're right! It may be more 
> generic to classify these scenarios, such as: "What should happen if a 
> restarting node fails to get a RecoveryPath/Path message from its 
> downstream/upstream neighbor?", but I think it may be more clear to 
> address the specific cases in the draft at least during the initial stage.
> 
> Any comments are very welcome!
> 
> Best regards,
> 
> Dan
> 
> 
> 
>  
> ----- Original Message ----- 
> From: Olufemi Komolafe 
> To: [e-mail] ; [e-mail] 
> Cc: ccamp 
> Sent: Tuesday, September 19, 2006 8:45 PM
> Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
> 
> 
> Hi,
>  
> While reading this draft it occurred to me that perhaps it might be more 
> useful to approach this topic from the perspective of "What can go wrong 
> during graceful restart, what are the consequences and how can it be 
> fixed?" rather than focusing on the narrower topic of multiple 
> simultaneous nodal faults.
>  
> For example, Scenario 1 in the draft may be interpreted as "What should 
> happen if a (non-ingress) restarting node fails to get a RecoveryPath 
> message from its downstream neighbour?", Scenario 2 is "What should happen 
> if a (non-ingress) restarting node fails to get a Path message from its 
> upstream neighbour?" and so on.  Whether each of these scenarios arises 
> due to multiple simultaneous nodal faults (as in the draft) or any other 
> reason (e.g. a subsequent control channel failure, restarting node being 
> inundated with messages etc.) is, in my opinion, secondary.  I think the 
> key thing is to identify the potential problems and suggest appropriate 
> remedial actions, where the authors think existing documentation is 
> insufficient, rather than focusing on 5 different permutations of multiple 
> node graceful restart. 
>  
> Regards,
> Femi
>  
>  
> 
> 
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Zafar Ali (zali)
> Sent: 10 July 2006 04:04
> To: [e-mail]; [e-mail]
> Cc: ccamp
> Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
>  
> Dear Authors, 
>  
> This is Deja-vu to me.... 
>  
> Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on 
> multiple node restart case and was rejected by the WG as addressing 
> multiple node restart case is NOT a goal (suffers from the law of 
> diminishing return). In other words the following statement in the ID- 
>  
>    "[GR-EXT] also extends the Hello message to exchange information about 
>    the ability to support the RecoveryPath message. 
>    The examples and procedures in [GR-EXT] focus on the description of a 
>    single node restart when adjacent network nodes are operative. 
>    Although the procedures are equally applicable to multi-node restarts, 
>    no detailed explanation is provided." 
>  
> is not accurate. Please see section 4 on the earlier version of the 
> [GR-EXT], 
> http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt
> . 
>  
> Thanks
>  
> Regards... Zafar 
>  
> 
> 
> 
> 
> 





Envelope-to: [e-mail]
Delivery-date: Sat, 30 Sep 2006 05:44:05 +0000
Date: Sat, 30 Sep 2006 13:42:01 +0800
From: Dan Li <[e-mail]>
Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
To: [e-mail]
Cc: ccamp <[e-mail]>, Olufemi Komolafe <[e-mail]>, [e-mail], [e-mail]
Message-id: <00fa01c6e453$271390d0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Dimitri,

There is nothing wrong with the GR draft, the mechanism described in that draft doesn't need any remedial patch, and it is applied to this draft. The reason we started working on this draft is try to clarify the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered depending on the order in which the nodes restart.

Thanks,

Dan

----- Original Message ----- 
From: <[e-mail]>
To: "Dan Li" <[e-mail]>
Cc: "ccamp" <[e-mail]>; "Olufemi Komolafe" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 27, 2006 12:50 AM
Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,


> hi dan 
> 
> yes i have a very practical issue - the document would then deal with 
> remedial to remedial - ... but do we have any feedback on initial 
> remedials ?
> 
> thanks,
> - d. 
> 
> 
> 
> 
> 
> Dan Li <[e-mail]>
> Sent by: [e-mail]
> 25/09/2006 09:27
>  
>         To:     Olufemi Komolafe <[e-mail]>, [e-mail]
>         cc:     ccamp <[e-mail]>
>         Subject:        Re: Comments on 
> draft-li-ccamp-multinodes-gr-proc-00.txt,
> 
> 
> Hi Femi,
> 
> Thanks for your valuable suggestion! 
> 
> The intention for this draft is clarify the procedures for multi-nodes 
> restart, so five typical scenarios have been listed in the draft, I think 
> most of the failed cases are covered by these five scenarios. As you have 
> pointed out, these scenarios may be raised due to multiple nodes fail, or 
> a subsequent control channel failure. Yes, you're right! It may be more 
> generic to classify these scenarios, such as: "What should happen if a 
> restarting node fails to get a RecoveryPath/Path message from its 
> downstream/upstream neighbor?", but I think it may be more clear to 
> address the specific cases in the draft at least during the initial stage.
> 
> Any comments are very welcome!
> 
> Best regards,
> 
> Dan
> 
> 
> 
>  
> ----- Original Message ----- 
> From: Olufemi Komolafe 
> To: [e-mail] ; [e-mail] 
> Cc: ccamp 
> Sent: Tuesday, September 19, 2006 8:45 PM
> Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
> 
> 
> Hi,
>  
> While reading this draft it occurred to me that perhaps it might be more 
> useful to approach this topic from the perspective of "What can go wrong 
> during graceful restart, what are the consequences and how can it be 
> fixed?" rather than focusing on the narrower topic of multiple 
> simultaneous nodal faults.
>  
> For example, Scenario 1 in the draft may be interpreted as "What should 
> happen if a (non-ingress) restarting node fails to get a RecoveryPath 
> message from its downstream neighbour?", Scenario 2 is "What should happen 
> if a (non-ingress) restarting node fails to get a Path message from its 
> upstream neighbour?" and so on.  Whether each of these scenarios arises 
> due to multiple simultaneous nodal faults (as in the draft) or any other 
> reason (e.g. a subsequent control channel failure, restarting node being 
> inundated with messages etc.) is, in my opinion, secondary.  I think the 
> key thing is to identify the potential problems and suggest appropriate 
> remedial actions, where the authors think existing documentation is 
> insufficient, rather than focusing on 5 different permutations of multiple 
> node graceful restart. 
>  
> Regards,
> Femi
>  
>  
> 
> 
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Zafar Ali (zali)
> Sent: 10 July 2006 04:04
> To: [e-mail]; [e-mail]
> Cc: ccamp
> Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
>  
> Dear Authors, 
>  
> This is Deja-vu to me.... 
>  
> Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on 
> multiple node restart case and was rejected by the WG as addressing 
> multiple node restart case is NOT a goal (suffers from the law of 
> diminishing return). In other words the following statement in the ID- 
>  
>    "[GR-EXT] also extends the Hello message to exchange information about 
>    the ability to support the RecoveryPath message. 
>    The examples and procedures in [GR-EXT] focus on the description of a 
>    single node restart when adjacent network nodes are operative. 
>    Although the procedures are equally applicable to multi-node restarts, 
>    no detailed explanation is provided." 
>  
> is not accurate. Please see section 4 on the earlier version of the 
> [GR-EXT], 
> http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt
> . 
>  
> Thanks
>  
> Regards... Zafar 
>  
> 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Sep 2006 11:02:46 +0000
Message-ID: <027a01c6e2ed$4acaa980$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: New Liaison Statement, "Response to liaisons on G.8110.1" 
Date: Thu, 28 Sep 2006 11:59:41 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Please see the liaison tracker for a response from the ITU-T on T-MPLS.

This liaison includes some text on the motivations for T-MPLS and starts to 
build a picture of what the T-MPLS control plane might be expected to do.

Adrian
----- Original Message ----- 
From: "Greg Jones (ITU-T SG 15)" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
Sent: Wednesday, September 27, 2006 4:35 PM
Subject: New Liaison Statement, "Response to liaisons on G.8110.1"


>
> Title: Response to liaisons on G.8110.1
> Submission Date: 2006-09-27
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=265
> Please reply by 2006-10-30
>
> From: Greg Jones(ITU-T SG 15) <[e-mail]>
> To: IETF([e-mail], [e-mail], [e-mail], 
> [e-mail], [e-mail], [e-mail])
> Cc: [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> [e-mail]
> Reponse Contact: [e-mail]
> [e-mail]
> Technical Contact: [e-mail]
> Purpose: For comment
> Body:
> Attachment(s):
>     Response to liaisons on G.8110.1 - body text 
> (https://datatracker.ietf.org/documents/LIAISON/file367.doc) 





Envelope-to: [e-mail]
Delivery-date: Tue, 26 Sep 2006 23:16:17 +0000
Date: Tue, 26 Sep 2006 16:14:57 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4631 on Link Management Protocol (LMP) Management Information Base (MIB)
From: [e-mail]
Cc: [e-mail], [e-mail]

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4631

        Title:      Link Management Protocol (LMP) Management 
                    Information Base (MIB) 
        Author:     M. Dubuc, T. Nadeau,
                    J. Lang, E. McGinnis,
                    A. Farrel
        Status:     Standards Track
        Date:       September 2006
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail], [e-mail], 
                    [e-mail]
        Pages:      83
        Characters: 152560
        Obsoletes:  RFC4327
        See-Also:   

        I-D Tag:    draft-ietf-ccamp-rfc4327bis-01.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4631.txt

This document provides minor corrections to and obsoletes RFC 4327.

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling the Link
Management Protocol (LMP).  [STANDARDS TRACK]

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Tue, 26 Sep 2006 16:52:22 +0000
To: Dan Li <[e-mail]>
Cc: ccamp <[e-mail]>, Olufemi Komolafe <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 26 Sep 2006 18:50:54 +0200
Content-Type: text/plain; charset="US-ASCII"

hi dan 

yes i have a very practical issue - the document would then deal with 
remedial to remedial - ... but do we have any feedback on initial 
remedials ?

thanks,
- d. 





Dan Li <[e-mail]>
Sent by: [e-mail]
25/09/2006 09:27
 
        To:     Olufemi Komolafe <[e-mail]>, [e-mail]
        cc:     ccamp <[e-mail]>
        Subject:        Re: Comments on 
draft-li-ccamp-multinodes-gr-proc-00.txt,


Hi Femi,

Thanks for your valuable suggestion! 

The intention for this draft is clarify the procedures for multi-nodes 
restart, so five typical scenarios have been listed in the draft, I think 
most of the failed cases are covered by these five scenarios. As you have 
pointed out, these scenarios may be raised due to multiple nodes fail, or 
a subsequent control channel failure. Yes, you're right! It may be more 
generic to classify these scenarios, such as: "What should happen if a 
restarting node fails to get a RecoveryPath/Path message from its 
downstream/upstream neighbor?", but I think it may be more clear to 
address the specific cases in the draft at least during the initial stage.

Any comments are very welcome!

Best regards,

Dan



 
----- Original Message ----- 
From: Olufemi Komolafe 
To: [e-mail] ; [e-mail] 
Cc: ccamp 
Sent: Tuesday, September 19, 2006 8:45 PM
Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,


Hi,
 
While reading this draft it occurred to me that perhaps it might be more 
useful to approach this topic from the perspective of "What can go wrong 
during graceful restart, what are the consequences and how can it be 
fixed?" rather than focusing on the narrower topic of multiple 
simultaneous nodal faults.
 
For example, Scenario 1 in the draft may be interpreted as "What should 
happen if a (non-ingress) restarting node fails to get a RecoveryPath 
message from its downstream neighbour?", Scenario 2 is "What should happen 
if a (non-ingress) restarting node fails to get a Path message from its 
upstream neighbour?" and so on.  Whether each of these scenarios arises 
due to multiple simultaneous nodal faults (as in the draft) or any other 
reason (e.g. a subsequent control channel failure, restarting node being 
inundated with messages etc.) is, in my opinion, secondary.  I think the 
key thing is to identify the potential problems and suggest appropriate 
remedial actions, where the authors think existing documentation is 
insufficient, rather than focusing on 5 different permutations of multiple 
node graceful restart. 
 
Regards,
Femi
 
 



From: [e-mail] [mailto:[e-mail]] On Behalf 
Of Zafar Ali (zali)
Sent: 10 July 2006 04:04
To: [e-mail]; [e-mail]
Cc: ccamp
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
 
Dear Authors, 
 
This is Deja-vu to me.... 
 
Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on 
multiple node restart case and was rejected by the WG as addressing 
multiple node restart case is NOT a goal (suffers from the law of 
diminishing return). In other words the following statement in the ID- 
 
   "[GR-EXT] also extends the Hello message to exchange information about 
   the ability to support the RecoveryPath message. 
   The examples and procedures in [GR-EXT] focus on the description of a 
   single node restart when adjacent network nodes are operative. 
   Although the procedures are equally applicable to multi-node restarts, 
   no detailed explanation is provided." 
 
is not accurate. Please see section 4 on the earlier version of the 
[GR-EXT], 
http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt
. 
 
Thanks
 
Regards... Zafar 
 






Envelope-to: [e-mail]
Delivery-date: Tue, 26 Sep 2006 15:51:00 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZeuzTK0fKQIXWbe/ybDW3J6NpzJLR9D9z0PCUVmX04B7+TVPJoTrTEZLpmzAA30bAYQ2F10C2p1PzLYgEhE2nJMKZ4Zih/LMrFF4l0q95sJ5ik8FVxpSdOl83a4ZABfLxyW44JAWfDg5K+NfLVWNhq5F2GB/HsON7pVmNg+TvxU=
Message-ID: <[e-mail]>
Date: Tue, 26 Sep 2006 11:49:12 -0400
From: "Peng He" <[e-mail]>
To: [e-mail]
Subject: A New I.D.: A Novel Framework for Inter-area MPLS Optimal Routing
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Dear all,

We just published a new Internet Draft: A Novel Framework for
Inter-area MPLS Optimal Routing
(http://www.ietf.org/internet-drafts/draft-he-ccamp-optimal-routing-00.txt).
 Our general motive is to try to build up a framework for MPLS (even
GMPLS possibly) inter-area TE, which can satisfy the inter-area TE
requirements defined in RFC 4105. Please note that our framework in
the draft can achieve inter-area MPLS optimal routing with good
backward compatibility; and, it is different with PCE-based
approaches.

Any comments are very welcomed!

Best Regards,
Peng He

PS: The following is publishing information of the draft:

A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : A Novel Framework for Inter-area MPLS Optimal Routing
> Author(s) : P. He, G. Bochmann
> Filename : draft-he-ccamp-optimal-routing-00.txt
> Pages : 16
> Date : 2006-9-25
>
> We propose a novel framework for inter-area MPLS optimal routing. The
> key to our proposal lies in deploying an overlaid star optical
> network in the OSPF backbone area and introducing the concept of
> ""virtual area border routers"" (v-ABRs). Compared with other
> proposals, our framework can provide globally optimized inter-area
> routing and has very good compatibility to existing traditional
> IP/MPLS routers.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-he-ccamp-optimal-routing-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-he-ccamp-optimal-routing-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-he-ccamp-optimal-routing-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Sep 2006 07:29:51 +0000
Date: Mon, 25 Sep 2006 15:27:29 +0800
From: Dan Li <[e-mail]>
Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
To: Olufemi Komolafe <[e-mail]>, [e-mail]
Cc: ccamp <[e-mail]>
Message-id: <00ee01c6e074$0ed0f040$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Femi,

Thanks for your valuable suggestion! 

The intention for this draft is clarify the procedures for multi-nodes restart, so five typical scenarios have been listed in the draft, I think most of the failed cases are covered by these five scenarios. As you have pointed out, these scenarios may be raised due to multiple nodes fail, or a subsequent control channel failure. Yes, you're right! It may be more generic to classify these scenarios, such as: "What should happen if a restarting node fails to get a RecoveryPath/Path message from its downstream/upstream neighbor?", but I think it may be more clear to address the specific cases in the draft at least during the initial stage.

Any comments are very welcome!

Best regards,

Dan



 
----- Original Message ----- 
From: Olufemi Komolafe 
To: [e-mail] ; [e-mail] 
Cc: ccamp 
Sent: Tuesday, September 19, 2006 8:45 PM
Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,


Hi,
 
While reading this draft it occurred to me that perhaps it might be more useful to approach this topic from the perspective of "What can go wrong during graceful restart, what are the consequences and how can it be fixed?" rather than focusing on the narrower topic of multiple simultaneous nodal faults.
 
For example, Scenario 1 in the draft may be interpreted as "What should happen if a (non-ingress) restarting node fails to get a RecoveryPath message from its downstream neighbour?", Scenario 2 is "What should happen if a (non-ingress) restarting node fails to get a Path message from its upstream neighbour?" and so on.  Whether each of these scenarios arises due to multiple simultaneous nodal faults (as in the draft) or any other reason (e.g. a subsequent control channel failure, restarting node being inundated with messages etc.) is, in my opinion, secondary.  I think the key thing is to identify the potential problems and suggest appropriate remedial actions, where the authors think existing documentation is insufficient, rather than focusing on 5 different permutations of multiple node graceful restart.   
 
Regards,
Femi
 
 



From: [e-mail] [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
Sent: 10 July 2006 04:04
To: [e-mail]; [e-mail]
Cc: ccamp
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
 
Dear Authors, 
 
This is Deja-vu to me.... 
 
Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on multiple node restart case and was rejected by the WG as addressing multiple node restart case is NOT a goal (suffers from the law of diminishing return). In other words the following statement in the ID- 
 
   "[GR-EXT] also extends the Hello message to exchange information about 
   the ability to support the RecoveryPath message. 
   The examples and procedures in [GR-EXT] focus on the description of a 
   single node restart when adjacent network nodes are operative. 
   Although the procedures are equally applicable to multi-node restarts, 
   no detailed explanation is provided." 
 
is not accurate. Please see section 4 on the earlier version of the [GR-EXT], http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt. 
 
Thanks
 
Regards... Zafar 
 



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Sep 2006 14:25:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DE52.CBE16254"
Subject: question on draft-ietf-ccamp-gmpls-recovery-e2e-signaling
Date: Fri, 22 Sep 2006 15:24:21 +0100
Message-ID: <[e-mail]>
Thread-Topic: question on draft-ietf-ccamp-gmpls-recovery-e2e-signaling
Thread-Index: AcbeUsv260Z4fGWJTmy31BkUFKv7vg==
From: "Alan Davey" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DE52.CBE16254
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi
=20
I have a question about the use of end-to-end recovery signaling in
conjunction with graceful restart following nodal faults.
=20
Is it expected that the end-to-end recovery signaling protocol will
handle the restart of either of the ingress or egress nodes during
switchover or reversion processing, where that node implements graceful
restart mechanisms as described in RFC3473?
=20
If so then what is the effect on, for example, the end-to-end switchover
request/response procedure of one of the end-nodes restarting?
=20
Thanks in advance
=20
Alan
=20
------------------------------------
Alan Davey
Data Connection Ltd
Tel:   [phone]
Fax:   [phone]
Email: [e-mail]
Web:   http://www.dataconnection.com <http://www.dataconnection.com/>=20

------_=_NextPart_001_01C6DE52.CBE16254
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006>Hi</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D070351413-22092006>I have =
a question=20
about the use of end-to-end recovery signaling in conjunction with =
graceful=20
restart following nodal faults.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D070351413-22092006>Is it =
expected that=20
the end-to-end recovery signaling protocol will handle the restart of =
either of=20
the ingress or egress nodes during switchover or reversion processing, =
where=20
that node implements graceful restart mechanisms as described in=20
RFC3473?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D070351413-22092006>If so =
then what is=20
the effect on, for example, the end-to-end switchover request/response =
procedure=20
of one of the end-nodes restarting?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D070351413-22092006>Thanks =
in=20
advance</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006>Alan</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D070351413-22092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D070351413-22092006>
<DIV align=3Dleft><FONT face=3DFixedsys=20
size=3D2>------------------------------------</FONT></DIV>
<DIV align=3Dleft><FONT face=3DFixedsys size=3D2>Alan Davey</FONT></DIV>
<DIV align=3Dleft><FONT face=3DFixedsys size=3D2>Data Connection =
Ltd</FONT></DIV>
<DIV align=3Dleft><FONT face=3DFixedsys size=3D2>Tel:&nbsp;&nbsp; +44 20 =
8366=20
1177</FONT></DIV>
<DIV align=3Dleft><FONT face=3DFixedsys size=3D2>Fax:&nbsp;&nbsp; +44 20 =
8363=20
1039</FONT></DIV>
<DIV align=3Dleft><FONT face=3DFixedsys size=3D2>Email: <A=20
href=3D"mailto:[e-mail]">Alan.Davey@dataconnection.c=
om</A></FONT></DIV>
<DIV align=3Dleft><FONT face=3DFixedsys size=3D2>Web:&nbsp;&nbsp; <A=20
href=3D"http://www.dataconnection.com/">http://www.dataconnection.com</A>=
</FONT></DIV></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6DE52.CBE16254--



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Sep 2006 13:24:46 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-54-235550940
Message-Id: <[e-mail]>
Cc: <[e-mail]>, "Ross Callon" <[e-mail]>, <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01
Date: Fri, 22 Sep 2006 09:22:57 -0400
To: "Adrian Farrel" <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=52628; t=1158931387; x=1159795387; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:JP=20Vasseur=20<[e-mail]> |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01; X=v=3Dcisco.com=3B=20h=3DuG5NUr9tkIvBpzVKn0luCin5Z/4=3D; b=R0Nuf+Nxd1FrQlOyHNrimk3GgvgHddaO5u1NaqsYVjc9C+I/Deam5Qn4FEnJSTG+xm3mDWuH smO8mu+qjv5zdok+Ptn0doCc1Cn4o6LN2WluXno2gO1VLlCAi/Rsn2qQ;
Authentication-Results: sj-dkim-7.cisco.com; header.From=[e-mail]; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; );

--Apple-Mail-54-235550940
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi Adrian,

On Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote:

> Hi JP,
>
> Thanks for addressing the comments. I have forwarded these to the  
> Routing Directorate and copied them on this email to let them  
> respond if they want.

OK

> But here are my comments:
>

in line,

>>> 1) The Tail-end name field facilitates LSP identification. Is this
>>> a new form of LSP identification?
>>> If it is not new, then there should be a reference to RFC3209 and a
>>> statement of which RFC3209 fields are mapped to this IGP field.
>>> If it is not new then there is a significant concern that a new
>>> identification is being introduced when it is not needed.
>>
>> As indicated in the document the string refers to a "Tail-end" name,
>> not an TE LSP name: thus it does not replace the session name of the
>> SESSION-ATTRIBUTE object defined in RFC3209.
>
> Hmmm, yes it is not an LSP name, but recall that the LSP is  
> identified by a combination of Session and Sender Template, and  
> that the Session includes the destination IP address. In Section  
> 3.2 I see:
>   - A Tail-end name: string used to ease the TE-LSP naming.
> and in Section 4.1:
>   - A Tail-end name: a variable length field used to facilitate the TE
>   LSP identification.

Ah I see your point now. Just bad wording, it should have read "
The idea is not to use that field for LSP identification per say but  
to ease the management, troubleshooting, ...
For example, an implementation could form the session name based on  
the strings on these fields.

A Tail-end name: name of the Tail-end LSR.

+ see below

>
> These definitions seem to imply that the tail-end name is used as  
> an identifier for the LSP. The question that will be asked is: How  
> does this identification of an LSP differ from the conventional  
> identification of the LSP?  Given that you also have:
>   - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
>   tail-end TE LSP address by other LSRs belonging to the same mesh-
>   group
> it appears that the tail-name is superfluous information.
>

Well having the name definitely helps for management,  
troubleshooting, ...

> So, perhaps the name is present for diagnostic purposes? Perhaps it  
> is there to ease OAM? But it does not seem to play any role in the  
> protocol procedures as it is not explicitly mentioned later in the  
> I-D (e.g. Section 5).
>

OK let me try to clarify adding the following text then:

The aim of the Tail-end address field is to provide a way to quickly  
identify the tail-end LSR originating the TE-MESH-GROUP and could be  
used for various purposes such such troubleshooting, management and  
so on. It does not interfere by any mean with the TE LSP attributes  
used to identify a TE LSP.

Does that clarify ?

> How would a node behave if it received a mesh group advertisement  
> that indicated a tail-end address that did not appear to match its  
> record of the tail-end name?
>
>>> 2) The document mentions that the number of mesh groups is limited
>>> but potentially (depending on encoding) provides for binary
>>> encoding for 2^32-1 groups (although this might be constrained by
>>> OSPF's limit of a TLV size to 2^16 bytes.
>>> The document (and the authors) state that scaling of these
>>> extensions is not an issue because only a small number of mesh
>>> groups are likely to be in existence in a network, and any one
>>> router is unlikely to participate in more than a very few.
>>> There are two concerns:
>>> a) Whenever we say that something in the Internet is limited,
>>> history usually proves us wrong.
>>
>> And that's undoubtedly a good news :-)
>>
>>> Indeed, there is already a
>>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a
>>> similar mechanism for a problem that would have far more groups.
>>
>> Two comments:
>> - Mesh groups are used to set up TE LSP meshes. If we consider let
>> say 10 meshes comprising 100 routers each, that gives us 99,000 TE
>> LSPs. One can easily see that the number of meshes is unlikely to
>> explode in a foreseeable future. If it turns out to be the case,
>> we'll have other scalability issues to fix before any potential with
>> the IGP.
>
> What about 100 meshes comprising 10 routers each?

Note that would still be very reasonable ;-)

> I make that only 9,000 TE LSPs.
>
> So clearly the scaling of MPLS-TE is not directly related to the  
> scaling of automesh.
>

Well you see my point ... since these extensions are used to set up  
TE LSPs, in the vast majority of the realistic cases you'll end up  
with scalability concerns with RSVP before seeing any IGP scalability  
issue.

> What this comes down to is your statement about how automesh will  
> be used. I think we can all accept that this is the problem space  
> that you intend to deploy in, and that is great. But the original  
> point from the Routing Directorate was that there is nothing in the  
> I-D that imposes this restriction. So how can we say that the  
> protocol extensions will scale?

And that is true with pretty much every protocol: one could always  
come up with a scenario where a bad usage of the protocol or a broken  
implementation may be a concern. Anyway, let me try to propose some  
text to close on this:

OLD:

It is expected that the number of mesh-groups be very limited (to at  
most 10 or so).
Moreover, TE mesh-group membership should not change frequently: each  
time an LSR joins or leaves a new TE mesh-group.

NEW:
The aim of the IGP extensions proposed in this document is to ease  
the provisioning of TE meshes, the number of which is generally very  
limited (10 at most or so), and should stay of this order of  
magnitude at least in a foreseeable future. Furthermore, such TE  
meshes are not expected to change frequently and thus the TE mesh- 
group membership is likely to be very stable (each time an LSR joins  
or leaves a new TE mesh-group, which is a not a frequent). An  
implementation SHOULD support mechanisms to control the frequency at  
which an LSR joins/leaves a particular a TE mesh group.

Does that address your concern ?

>
>> - More importantly, the dynamics of joining a TE mesh is such that
>> IGP updates are used to advertise to TE mesh group membership change
>> (join or prune), which are indeed expected to be very unfrequent.
>
> Again, the concern raised is that the problem space you intend to  
> deploy in is, indeed, limited in this way. All good. But how can we  
> say whether the protocol extensions will be used differently in the  
> future? What controls are there over constructing a mesh where  
> joins and prunes are frequent?
>
>>> b) The I-D does not itself impose any reasonable limits on the
>>> number of groups with the potential for a single router (by
>>> misconfiguration, design, or malice) advertising a very large
>>> number of groups.
>>> Thus, it appears that the scaling concerns are not properly
>>> addressed in this I-D.
>>
>> Not sure to see the point here. If indeed, a large number of TE MESH
>> GROUPs were advertised, this would not impact the other LSRs since
>> they would not create any new TE LSPs trying to join the new TE-MESH-
>> GROUP. In term of amount of flooded information, this should not be a
>> concern either (handled by routing). We clarified this in the
>> security section.
>
> The impact on the other LSRs is exactly flooding question. Covering  
> that in the security section is fine for the misconfiguration and  
> malice cases.
>
>>> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL
>>> and must at most appear once in a OSPF Router Information LSA or
>>> ISIS Router Capability TLV." but for addition/removal it mentions
>>> "conversely, if the LSR leaves a mesh-group the corresponding entry
>>> will be removed from the TE-MESH-GROUP TLV."
>>> What are these "entries" referring to - that there is a top-level
>>> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions
>>> "No sub-TLV is currently defined for the TE-mesh-group TLV") ?
>>>
>>> AF>> My comment on this is that the definition of the TLVs seems
>>> AF>> unclear.
>>> AF>> From figure 2, it appears that some additional information  
>>> can be
>>> AF>> present in the TLV after the fields listed, and (reading
>>> AF>> between the lines) it would appear that this additional
>>> AF>> information is a series of repeats of the set of fields to
>>> AF>> define multiple mesh groups.
>>> AF>> This could usefully be clarified considerably.
>>
>>
>> You're absolutely right. The figures have been modified:
>>
>> (example show below):
>
> [SNIP]
> Looks good to me.
>
>>> AF>> But it is now unclear to me whether a single router can be a
>>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that
>>> AF>> these cannot be mixed within a single TLV, and multiple
>>> AF>> TLVs (one IPv4 and one IPv6) are prohibited.
>>
>> OK the text requires some clarification. What is prohibited is to
>> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is
>> permitted. New proposed text to clarify:
>>
>> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and
>> one IPv6 instance MUST appear in a OSPF Router Information LSA or
>> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or
>> IPv6) occurs more than once within the OSPF Router Information LSA,
>> only the first instance is processed, subsequent TLV(s) will be
>> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4
>> or IPv6) occurs more than once within the ISIS Router capability TLV,
>> only the first instance is processed, subsequent TLV(s) will be
>> silently ignored.
>
> OK. That's fine.
> I think you want to make a couple of changes:
> - "at most one instance MUST appear" is ambiguous since it will
>  be confused with "an instance MUST appear". I suggest you
>  reword as "MUST NOT include more than one of each of"
> - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs
>  more than once" should really be phrased as "If the either the
>  IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more
>  than once".  Ditto for the IS-IS sub-TLV.
> - Two instances of "will be silently ignored" should read "SHOULD
>  be silently ignored"

Fixed, thanks !

>
>>> 4) Small terminology issue in section 5.1 it says: "Note that both
>>> operations can be performed in the context of a single refresh."
>>> This is not a refresh. It is a trigger/update. A better term for
>>> OSPF would be "LSA origination".
>>
>> OK fixed (I used the term "Update"), thanks.
>
> OK
>
>>> 5) Please state the applicability to OSPF v2 and or v3. Note that
>>> the Router_Cap document covers both v2 and v3
>>
>> Indeed, Thanks for the comments.  The OSPFv3 aspects have been
>> incorporated. Here is the new text:
>
> [SNIP]
> OK
>
>>> 6) The term "fairly static" at the end of section 5.1 is
>>> meaningless without some relative context.
>>> Presumably this relates to the number times an LSR joins or leaves
>>> a mesh group over time.
>>> Is it intended to be relative to the IGP refresh period?
>>> Please clarify in an objective rather than a subjective way.
>>
>>
>> Right, this requires clarification. Here is the new text: Moreover,
>> TE mesh-group membership should not change frequently: each time an
>> LSR joins or leaves a new TE mesh-group.
>
> I could live with this, personally. We'll see whether we get any  
> more comments.
> I think the nub will be:
> 1. whether your "should not" can be "SHOULD NOT"
> 2. what does "frequently mean"?
> 3. what is there in this I-D to say that an LSR does not join/leave a
>   TE mesh-group very often?
>

Hopefully I clarified with the text above.

>> I guess that this is sufficiently explicit: it is a well-known fact
>> that LSRs are infrequently added or removed to a TE mesh.
>
> :-) Very well known. In fact, my mother was commenting on it to me  
> only the other day ;-)
>

ah so she should talk to my kids then ... we can work this out ;-)))

> Consider the case where PE membership of an automesh is dependent  
> on whether there are C-nodes subscribed to some service.
>
> Perhaps this well known fact could be noted in the Introduction to  
> this I-D which is AFAIK the only IETF document on the subject of  
> automesh.

OK, see the proposed text, and let me know what you think, I do think  
that this is sufficient but let me know.

>
>>> 7) The security section (section 8) is inadequate and will
>>> undoubtedly be rejected by the security ADs. At the very least, the
>>> I-D needs a paragraph (i.e. more than one or two lines) explaining
>>> why there are no new security considerations. But what would be the
>>> impact of adding false mesh groups to a TLV? Is there anything
>>> (dangerous) that can be learned about the network by inspecting
>>> mesh group TLVs?
>>
>> The following section has been added:
>
> [SNIP]
> OK. Let's run with that and see how much we get beaten up by the  
> Security experts.

OK, thanks.

cheers,

JP.

>
> Cheers,
> Adrian


--Apple-Mail-54-235550940
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Hi Adrian,<DIV><BR><DIV><DIV>On =
Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Hi JP,</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Thanks for addressing the =
comments. I have forwarded these to the Routing Directorate and copied =
them on this email to let them respond if they want. =
<BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OK</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">But here are my =
comments:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>in =
line,</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">1) The Tail-end name field facilitates LSP =
identification. Is this</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a new form of =
LSP identification?</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">If it is not new, then =
there should be a reference to RFC3209 and a</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">statement of which RFC3209 fields are mapped to this =
IGP field.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">If it is not new then there is a =
significant concern that a new</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">identification is being introduced when it is not needed.</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">As indicated in the document the string refers to a =
"Tail-end" name,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">not an TE LSP name: thus it does =
not replace the session name of the</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">SESSION-ATTRIBUTE object defined in RFC3209.</DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Hmmm, =
yes it is not an LSP name, but recall that the LSP is identified by a =
combination of Session and Sender Template, and that the Session =
includes the destination IP address. In Section 3.2 I see:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0 </SPAN>- A =
Tail-end name: string used to ease the TE-LSP naming.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">and in Section 4.1:</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- A Tail-end name: a variable =
length field used to facilitate the TE</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>LSP =
identification.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Ah I see your point now. =
Just bad wording, it should have read "</DIV>The idea is not to use that =
field for LSP identification per say but to ease the management, =
troubleshooting, ...</DIV><DIV>For example, an implementation could form =
the session name based on the strings on these fields.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><I>A Tail-end name: name of =
the Tail-end LSR.</I></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>+ see =
below</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">These =
definitions seem to imply that the tail-end name is used as an =
identifier for the LSP. The question that will be asked is: How does =
this identification of an LSP differ from the conventional =
identification of the LSP?<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Given that you also have:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- A Tail-end address: an IPv4 =
or IPv6 IP address to be used as a</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>tail-end TE LSP address by =
other LSRs belonging to the same mesh-</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>group</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">it appears that the tail-name is superfluous =
information.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Well having the name =
definitely helps for management, troubleshooting, =
...</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">So, perhaps the name is present =
for diagnostic purposes? Perhaps it is there to ease OAM? But it does =
not seem to play any role in the protocol procedures as it is not =
explicitly mentioned later in the I-D (e.g. Section 5).</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OK let me try to clarify =
adding the following text then:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><I>The aim of the Tail-end =
address field is to provide a way to quickly identify the tail-end LSR =
originating the TE-MESH-GROUP and could be used for various purposes =
such such troubleshooting, management and so on. It does not interfere =
by any mean with the TE LSP attributes used to identify a TE =
LSP.</I></DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>Does =
that clarify ?</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">How =
would a node behave if it received a mesh group advertisement that =
indicated a tail-end address that did not appear to match its record of =
the tail-end name?</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">2) The document mentions that the number of mesh =
groups is limited</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">but potentially (depending on =
encoding) provides for binary</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">encoding for =
2^32-1 groups (although this might be constrained by</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">OSPF's limit of a TLV size to 2^16 bytes.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The document (and the authors) state that scaling of =
these</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">extensions is not an issue =
because only a small number of mesh</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">groups are =
likely to be in existence in a network, and any one</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">router is unlikely to participate in more than a =
very few.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">There are two =
concerns:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">a) Whenever we say that =
something in the Internet is limited,</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">history =
usually proves us wrong.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">And that's =
undoubtedly a good news :-)</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Indeed, =
there is already a</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">proposal =
(draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">similar mechanism for a problem that would have far =
more groups.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Two comments:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- Mesh groups are used to set up TE LSP meshes. If =
we consider let</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">say 10 meshes comprising 100 =
routers each, that gives us 99,000 TE</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">LSPs. =
One can easily see that the number of meshes is unlikely to</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">explode in a foreseeable future. If it turns out to =
be the case,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">we'll have other scalability =
issues to fix before any potential with</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the =
IGP.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">What about 100 meshes comprising =
10 routers each?</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Note that would still be =
very reasonable ;-)</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I make that only 9,000 TE LSPs.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">So =
clearly the scaling of MPLS-TE is not directly related to the scaling of =
automesh.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Well you see my point ... =
since these extensions are used to set up TE LSPs, in the vast majority =
of the realistic cases you'll end up with scalability concerns with RSVP =
before seeing any IGP scalability issue.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">What this comes down to is your statement about how =
automesh will be used. I think we can all accept that this is the =
problem space that you intend to deploy in, and that is great. But the =
original point from the Routing Directorate was that there is nothing in =
the I-D that imposes this restriction. So how can we say that the =
protocol extensions will scale?</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>And that is true with =
pretty much every protocol: one could always come up with a scenario =
where a bad usage of the protocol or a broken implementation may be a =
concern. Anyway, let me try to propose some text to close on =
this:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OLD:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>It is expected that the =
number of mesh-groups be very limited (to at most 10 or =
so).=A0</DIV><DIV>Moreover, TE mesh-group membership should not change =
frequently: each time an LSR joins or leaves a new TE =
mesh-group.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>NEW:</DIV><DIV>The aim of =
the IGP extensions proposed in this document is to ease the provisioning =
of TE meshes, the number of which is generally very limited (10 at most =
or so), and should stay of this order of magnitude at least in =
a=A0foreseeable future. Furthermore, such TE meshes are not expected to =
change frequently and thus the TE mesh-group membership is likely to be =
very stable (each time an LSR joins or leaves a new TE mesh-group, which =
is a not a frequent). An implementation SHOULD support=A0mechanisms to =
control the frequency at which an LSR joins/leaves a particular a TE =
mesh group.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV>Does =
that address your concern ?</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- More importantly, the dynamics =
of joining a TE mesh is such that</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IGP updates =
are used to advertise to TE mesh group membership change</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">(join or prune), which are indeed expected to be =
very unfrequent.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Again, the concern raised is =
that the problem space you intend to deploy in is, indeed, limited in =
this way. All good. But how can we say whether the protocol extensions =
will be used differently in the future? What controls are there over =
constructing a mesh where joins and prunes are frequent?</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE =
type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">b) The I-D =
does not itself impose any reasonable limits on the</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">number of groups with the potential for a single =
router (by</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">misconfiguration, design, or =
malice) advertising a very large</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">number of =
groups.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Thus, it appears that the =
scaling concerns are not properly</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">addressed in =
this I-D.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Not sure to see the point here. =
If indeed, a large number of TE MESH</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">GROUPs were =
advertised, this would not impact the other LSRs since</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">they would not create any new TE LSPs trying to join =
the new TE-MESH-</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">GROUP. In term of amount of =
flooded information, this should not be a</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">concern =
either (handled by routing). We clarified this in the</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">security section.</DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
impact on the other LSRs is exactly flooding question. Covering that in =
the security section is fine for the misconfiguration and malice =
cases.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<BLOCKQUOTE type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">3) The document mentions that "The TE-MESH-GROUP TLV =
is OPTIONAL</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">and must at most appear once in =
a OSPF Router Information LSA or</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ISIS Router =
Capability TLV." but for addition/removal it mentions</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">"conversely, if the LSR leaves a mesh-group the =
corresponding entry</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">will be removed from the =
TE-MESH-GROUP TLV."</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">What are these "entries" =
referring to - that there is a top-level</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">TE-MESH-GROUP TLV with multiple sub-TLVs (but the document =
mentions</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">"No sub-TLV is currently defined =
for the TE-mesh-group TLV") ?</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; My comment on this is =
that the definition of the TLVs seems</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">AF&gt;&gt; unclear.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; =46rom figure 2, =
it appears that some additional information can be</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">AF&gt;&gt; present in the TLV after the fields =
listed, and (reading</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; between the =
lines) it would appear that this additional</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">AF&gt;&gt; information is a series of repeats of the set of fields =
to</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; ">AF&gt;&gt; define multiple mesh =
groups.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; This could usefully =
be clarified considerably.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">You're absolutely right. The =
figures have been modified:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">(example show below):</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">[SNIP]</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Looks good to =
me.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<BLOCKQUOTE type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">AF&gt;&gt; But it is now unclear to me whether a =
single router can be a</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; member of IPv4 =
an IPv6 mesh groups. It would seem that</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">AF&gt;&gt; these cannot be mixed within a single TLV, and =
multiple</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; TLVs (one IPv4 and =
one IPv6) are prohibited.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">OK the text =
requires some clarification. What is prohibited is to</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">have two IPv4 sub-TLV or two IPv6 sub-TLV but one of =
each is</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">permitted. New proposed text to =
clarify:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The TE-MESH-GROUP TLV is OPTIONAL and at most one =
IPv4 instance and</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">one IPv6 instance MUST appear in =
a OSPF Router Information LSA or</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ISIS Router =
Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IPv6) occurs more than once within the OSPF Router =
Information LSA,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">only the first instance is =
processed, subsequent TLV(s) will be</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">silently =
ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">or IPv6) occurs more than once within the ISIS =
Router capability TLV,</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">only the first instance is =
processed, subsequent TLV(s) will be</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">silently =
ignored.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">OK. That's fine.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I think you want to make a couple of =
changes:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- "at most one instance MUST =
appear" is ambiguous since it will</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>be confused with "an instance =
MUST appear". I suggest you</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>reword as "MUST NOT include =
more than one of each of"</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">- "If the =
OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0</SPAN>more =
than once" should really be phrased as "If the either the</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0</SPAN>IPv4 =
or IPv6 OSPF TE-MESH-GROUP TLV occurs more</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>than once".<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Ditto for the IS-IS =
sub-TLV.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- Two instances of "will be =
silently ignored" should read "SHOULD</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>be silently =
ignored"</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Fixed, thanks =
!</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">4) Small terminology issue in =
section 5.1 it says: "Note that both</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">operations =
can be performed in the context of a single refresh."</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">This is not a refresh. It is a trigger/update. A =
better term for</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">OSPF would be "LSA =
origination".</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">OK fixed (I used the term =
"Update"), thanks.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">OK</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">5) Please state the =
applicability to OSPF v2 and or v3. Note that</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">the Router_Cap document covers both v2 and v3</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Indeed, Thanks for the comments.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>The OSPFv3 aspects have =
been</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">incorporated. Here is the new =
text:</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">[SNIP]</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">OK</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">6) The term "fairly static" at the end of section =
5.1 is</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">meaningless without some =
relative context.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Presumably this relates to the =
number times an LSR joins or leaves</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a mesh group =
over time.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Is it intended to be relative to =
the IGP refresh period?</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Please =
clarify in an objective rather than a subjective way.</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Right, =
this requires clarification. Here is the new text: Moreover,</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">TE mesh-group membership should not change =
frequently: each time an</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">LSR joins or =
leaves a new TE mesh-group.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I could live =
with this, personally. We'll see whether we get any more =
comments.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">I think the nub will =
be:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">1. whether your "should not" can =
be "SHOULD NOT"</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">2. what does "frequently =
mean"?</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">3. what is there in this I-D to =
say that an LSR does not join/leave a</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>TE mesh-group very =
often?</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Hopefully I clarified with =
the text above.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "></DIV> <BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">I guess that this is =
sufficiently explicit: it is a well-known fact</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">that LSRs are infrequently added or removed to a TE =
mesh.</DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">:-) Very well known. In fact, my =
mother was commenting on it to me only the other day ;-)</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>ah so she should talk to my =
kids then ... we can work this out ;-)))</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Consider the case where PE membership of an automesh =
is dependent on whether there are C-nodes subscribed to some =
service.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Perhaps this well known fact could be noted in the =
Introduction to this I-D which is AFAIK the only IETF document on the =
subject of automesh.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OK, see the proposed text, =
and let me know what you think, I do think that this is sufficient but =
let me know.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">7) The security section (section =
8) is inadequate and will</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">undoubtedly =
be rejected by the security ADs. At the very least, the</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I-D needs a paragraph (i.e. more than one or two =
lines) explaining</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">why there are no new security =
considerations. But what would be the</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">impact =
of adding false mesh groups to a TLV? Is there anything</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">(dangerous) that can be learned about the network by =
inspecting</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">mesh group TLVs?</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The following section has been added:</DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">[SNIP]</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">OK. Let's run =
with that and see how much we get beaten up by the Security =
experts.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OK, thanks.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>cheers,</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>JP.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Cheers,</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Adrian<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-54-235550940--



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 16:50:37 +0000
Message-ID: <0f3f01c6dd9d$e30e7fa0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "JP Vasseur" <[e-mail]>
Cc: <[e-mail]>, "Ross Callon" <[e-mail]>, <[e-mail]>
Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01
Date: Thu, 21 Sep 2006 17:48:53 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi JP,

Thanks for addressing the comments. I have forwarded these to the Routing 
Directorate and copied them on this email to let them respond if they want. 
But here are my comments:

>> 1) The Tail-end name field facilitates LSP identification. Is this
>> a new form of LSP identification?
>> If it is not new, then there should be a reference to RFC3209 and a
>> statement of which RFC3209 fields are mapped to this IGP field.
>> If it is not new then there is a significant concern that a new
>> identification is being introduced when it is not needed.
>
> As indicated in the document the string refers to a "Tail-end" name,
> not an TE LSP name: thus it does not replace the session name of the
> SESSION-ATTRIBUTE object defined in RFC3209.

Hmmm, yes it is not an LSP name, but recall that the LSP is identified by a 
combination of Session and Sender Template, and that the Session includes 
the destination IP address. In Section 3.2 I see:
   - A Tail-end name: string used to ease the TE-LSP naming.
and in Section 4.1:
   - A Tail-end name: a variable length field used to facilitate the TE
   LSP identification.

These definitions seem to imply that the tail-end name is used as an 
identifier for the LSP. The question that will be asked is: How does this 
identification of an LSP differ from the conventional identification of the 
LSP?  Given that you also have:
   - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
   tail-end TE LSP address by other LSRs belonging to the same mesh-
   group
it appears that the tail-name is superfluous information.

So, perhaps the name is present for diagnostic purposes? Perhaps it is there 
to ease OAM? But it does not seem to play any role in the protocol 
procedures as it is not explicitly mentioned later in the I-D (e.g. Section 
5).

How would a node behave if it received a mesh group advertisement that 
indicated a tail-end address that did not appear to match its record of the 
tail-end name?

>> 2) The document mentions that the number of mesh groups is limited
>> but potentially (depending on encoding) provides for binary
>> encoding for 2^32-1 groups (although this might be constrained by
>> OSPF's limit of a TLV size to 2^16 bytes.
>> The document (and the authors) state that scaling of these
>> extensions is not an issue because only a small number of mesh
>> groups are likely to be in existence in a network, and any one
>> router is unlikely to participate in more than a very few.
>> There are two concerns:
>> a) Whenever we say that something in the Internet is limited,
>> history usually proves us wrong.
>
> And that's undoubtedly a good news :-)
>
>> Indeed, there is already a
>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a
>> similar mechanism for a problem that would have far more groups.
>
> Two comments:
>- Mesh groups are used to set up TE LSP meshes. If we consider let
> say 10 meshes comprising 100 routers each, that gives us 99,000 TE
> LSPs. One can easily see that the number of meshes is unlikely to
> explode in a foreseeable future. If it turns out to be the case,
> we'll have other scalability issues to fix before any potential with
> the IGP.

What about 100 meshes comprising 10 routers each?
I make that only 9,000 TE LSPs.

So clearly the scaling of MPLS-TE is not directly related to the scaling of 
automesh.

What this comes down to is your statement about how automesh will be used. I 
think we can all accept that this is the problem space that you intend to 
deploy in, and that is great. But the original point from the Routing 
Directorate was that there is nothing in the I-D that imposes this 
restriction. So how can we say that the protocol extensions will scale?

> - More importantly, the dynamics of joining a TE mesh is such that
> IGP updates are used to advertise to TE mesh group membership change
> (join or prune), which are indeed expected to be very unfrequent.

Again, the concern raised is that the problem space you intend to deploy in 
is, indeed, limited in this way. All good. But how can we say whether the 
protocol extensions will be used differently in the future? What controls 
are there over constructing a mesh where joins and prunes are frequent?

>> b) The I-D does not itself impose any reasonable limits on the
>> number of groups with the potential for a single router (by
>> misconfiguration, design, or malice) advertising a very large
>> number of groups.
>> Thus, it appears that the scaling concerns are not properly
>> addressed in this I-D.
>
>Not sure to see the point here. If indeed, a large number of TE MESH
>GROUPs were advertised, this would not impact the other LSRs since
>they would not create any new TE LSPs trying to join the new TE-MESH-
>GROUP. In term of amount of flooded information, this should not be a
>concern either (handled by routing). We clarified this in the
>security section.

The impact on the other LSRs is exactly flooding question. Covering that in 
the security section is fine for the misconfiguration and malice cases.

>> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL
>> and must at most appear once in a OSPF Router Information LSA or
>> ISIS Router Capability TLV." but for addition/removal it mentions
>> "conversely, if the LSR leaves a mesh-group the corresponding entry
>> will be removed from the TE-MESH-GROUP TLV."
>> What are these "entries" referring to - that there is a top-level
>> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions
>> "No sub-TLV is currently defined for the TE-mesh-group TLV") ?
>>
>> AF>> My comment on this is that the definition of the TLVs seems
>> AF>> unclear.
>> AF>> From figure 2, it appears that some additional information can be
>> AF>> present in the TLV after the fields listed, and (reading
>> AF>> between the lines) it would appear that this additional
>> AF>> information is a series of repeats of the set of fields to
>> AF>> define multiple mesh groups.
>> AF>> This could usefully be clarified considerably.
>
>
> You're absolutely right. The figures have been modified:
>
> (example show below):

[SNIP]
Looks good to me.

>> AF>> But it is now unclear to me whether a single router can be a
>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that
>> AF>> these cannot be mixed within a single TLV, and multiple
>> AF>> TLVs (one IPv4 and one IPv6) are prohibited.
>
> OK the text requires some clarification. What is prohibited is to
> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is
> permitted. New proposed text to clarify:
>
> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and
> one IPv6 instance MUST appear in a OSPF Router Information LSA or
> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or
> IPv6) occurs more than once within the OSPF Router Information LSA,
> only the first instance is processed, subsequent TLV(s) will be
> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4
> or IPv6) occurs more than once within the ISIS Router capability TLV,
> only the first instance is processed, subsequent TLV(s) will be
> silently ignored.

OK. That's fine.
I think you want to make a couple of changes:
- "at most one instance MUST appear" is ambiguous since it will
  be confused with "an instance MUST appear". I suggest you
  reword as "MUST NOT include more than one of each of"
- "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs
  more than once" should really be phrased as "If the either the
  IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more
  than once".  Ditto for the IS-IS sub-TLV.
- Two instances of "will be silently ignored" should read "SHOULD
  be silently ignored"

>> 4) Small terminology issue in section 5.1 it says: "Note that both
>> operations can be performed in the context of a single refresh."
>> This is not a refresh. It is a trigger/update. A better term for
>> OSPF would be "LSA origination".
>
>OK fixed (I used the term "Update"), thanks.

OK

>> 5) Please state the applicability to OSPF v2 and or v3. Note that
>> the Router_Cap document covers both v2 and v3
>
>Indeed, Thanks for the comments.  The OSPFv3 aspects have been
>incorporated. Here is the new text:

[SNIP]
OK

>> 6) The term "fairly static" at the end of section 5.1 is
>> meaningless without some relative context.
>> Presumably this relates to the number times an LSR joins or leaves
>> a mesh group over time.
>> Is it intended to be relative to the IGP refresh period?
>> Please clarify in an objective rather than a subjective way.
>
>
> Right, this requires clarification. Here is the new text: Moreover,
> TE mesh-group membership should not change frequently: each time an
> LSR joins or leaves a new TE mesh-group.

I could live with this, personally. We'll see whether we get any more 
comments.
I think the nub will be:
1. whether your "should not" can be "SHOULD NOT"
2. what does "frequently mean"?
3. what is there in this I-D to say that an LSR does not join/leave a
   TE mesh-group very often?

> I guess that this is sufficiently explicit: it is a well-known fact
> that LSRs are infrequently added or removed to a TE mesh.

:-) Very well known. In fact, my mother was commenting on it to me only the 
other day ;-)

Consider the case where PE membership of an automesh is dependent on whether 
there are C-nodes subscribed to some service.

Perhaps this well known fact could be noted in the Introduction to this I-D 
which is AFAIK the only IETF document on the subject of automesh.

>> 7) The security section (section 8) is inadequate and will
>> undoubtedly be rejected by the security ADs. At the very least, the
>> I-D needs a paragraph (i.e. more than one or two lines) explaining
>> why there are no new security considerations. But what would be the
>> impact of adding false mesh groups to a TLV? Is there anything
>> (dangerous) that can be learned about the network by inspecting
>> mesh group TLVs?
>
> The following section has been added:

[SNIP]
OK. Let's run with that and see how much we get beaten up by the Security 
experts.

Cheers,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 16:11:19 +0000
Message-ID: <0f2701c6dd98$65564d40$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "ccamp" <[e-mail]>
Subject: Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
Date: Thu, 21 Sep 2006 16:55:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original
Content-Transfer-Encoding: 8bit

Hi Jiang,

Yes, I read your I-D when it was published in November last year.

It seems to me that you were addressing a very specific sub-case of the 
graceful restart problem space. If we generalise to a linear network 
A-B-C-D-E-F with an LSP running from A to F, your draft handles the case 
where all four nodes B, C, D and E fail, and C and D subsequently recover, 
but have retained no LSP state. You are asking the question, how do nodes C 
and D know to exchange Hello messages.

The reasons why I limit your draft to such a narrow subset of the problem 
are:
- If any restarting node is adjacent to a node
  that remained active, the active node will
  send a Hello message and that will engage
  the graceful restart procedures
- If the restarting node had retained any
  LSP state, it would know about its neighbours
  and would be able to send Hello messages.

This seems like a very small corner case, and we do not usually design the 
protocols to optimise for this type of error condition. So long as there is 
*a* solution, we are usually happy. That said, if this is a problem that is 
causing you problems in the field, we should address it.

I note that your I-D has expired and I wonder what your plans are for this 
work.

Regards,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: "Olufemi Komolafe" <[e-mail]>
Cc: "ccamp" <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
Sent: Wednesday, September 20, 2006 3:57 AM
Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,


> Hello, everyone!
>
> We have put forward a mechanism to solve this problem in our
> draft "draft-jian-ccamp-multinodes-rsvp-restart-00" last year.
>
> We think that if multiple adjacent nodes restarted nearly at
> the same time, these nodes cannot learn about the GR capability
> from each other.
>
> The key of this problem is that how restarted node actively
> inform its GR(Graceful Restart) capability to neighbor nodes,
> especially some neighbor nodes are restarted nodes too.
>
> If you concern our mechanism, please read our draft for detail.
>
>
>
>
> Regard,
> Jiang Weilian
> ...............................................
> Add:   No.68 Zijinghua Rd,Yuhuatai District,
>        Nanjing. P.R.China.
> Zip:   210012
> Tel:   [phone]
> Mail:  [e-mail]
> .............................................
>
>
>
>
>
> "Olufemi Komolafe" <[e-mail]>
> ·¢¼þÈË£º [e-mail]
>
> 2006-09-19 20:45
>
>        ÊÕ¼þÈË£º        <[e-mail]>, <[e-mail]>
>        ³­ËÍ£º  "ccamp" <[e-mail]>
>        Ö÷Ì⣺  RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
>
>
> Hi,
>
> While reading this draft it occurred to me that perhaps it might be more
> useful to approach this topic from the perspective of ¡°What can go wrong
> during graceful restart, what are the consequences and how can it be
> fixed?¡± rather than focusing on the narrower topic of multiple
> simultaneous nodal faults.
>
> For example, Scenario 1 in the draft may be interpreted as ¡°What should
> happen if a (non-ingress) restarting node fails to get a RecoveryPath
> message from its downstream neighbour?¡±, Scenario 2 is ¡°What should
> happen if a (non-ingress) restarting node fails to get a Path message from
> its upstream neighbour?¡± and so on.  Whether each of these scenarios
> arises due to multiple simultaneous nodal faults (as in the draft) or any
> other reason (e.g. a subsequent control channel failure, restarting node
> being inundated with messages etc.) is, in my opinion, secondary.  I think
> the key thing is to identify the potential problems and suggest
> appropriate remedial actions, where the authors think existing
> documentation is insufficient, rather than focusing on 5 different
> permutations of multiple node graceful restart.
>
> Regards,
> Femi
>
>
>
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Zafar Ali (zali)
> Sent: 10 July 2006 04:04
> To: [e-mail]; [e-mail]
> Cc: ccamp
> Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
>
> Dear Authors,
>
> This is Deja-vu to me....
>
> Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on
> multiple node restart case and was rejected by the WG as addressing
> multiple node restart case is NOT a goal (suffers from the law of
> diminishing return). In other words the following statement in the ID-
>
>   "[GR-EXT] also extends the Hello message to exchange information about
>   the ability to support the RecoveryPath message.
>   The examples and procedures in [GR-EXT] focus on the description of a
>   single node restart when adjacent network nodes are operative.
>   Although the procedures are equally applicable to multi-node restarts,
>   no detailed explanation is provided."
>
> is not accurate. Please see section 4 on the earlier version of the
> [GR-EXT],
> http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt
> .
>
> Thanks
>
> Regards... Zafar
>
>
>
> --------------------------------------------------------
> 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.
>
>
>
>
> --------------------------------------------------------
> 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.
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 15:01:09 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 15:59:54 +0100
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: Acbddg77yvsiJyJpTXasuZ6O4lOTMwAALwBA
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

Thanks Loa.....this sounds OK to me and I'll go with the liaison as-is.


However, one point we should bear in mind and that has not been stated
so far is that the VLAN field assumes a different semantic in a co-ps
mode layer network (be this PBT or VLAN-XC swapping) compared to its
original cl-ps mode Ethernet layer network semantic.  In the co-ps mode
case it is either:
-	part of the trail termination address in PBT that does not get
swapped during forwarding, ie the trail sink term address is the
combination of DMAC+VCID;
-	a proxy for the trail termination address in VLAN-XC (BTW - I am
not clear what VLAN-XC layer network addresses are here) that could be
swapped on each link-connection.

AFAI understand the original IEEE intent of a VLAN was to create a
restricted broadcast domain within which a certain subset of the total
MAC address population reside.

These are quite different semantics.  So asking for clarification of
what IEEE mean by (and the scope of) swapping the VLAN field would still
not really be comparable to such an action in a co-ps mode layer
network.

regards Neil

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: 21 September 2006 13:03
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Proposed liaison response to IEEE
>=20
>=20
> All,
>=20
> there have been a number of correct statements in this short thread.
>=20
> Neil is right (given the layered network model) that Ethernet
> is a layer network and as such connectionless and packet oriented.
>=20
> Nurit is right that if you configure a VLAN on only to parts
> of an Ethernet bridge the frame will go through without=20
> looking at the MAC address
>=20
> Don is right that the liaison does not capture an earlier
> comment he made on the gels-list. Neither does it capture a=20
> comment made by Attila.
>=20
> However, if I understand what is happening here is that we
> need to clarify a paragraph in the liaison form the IEEE802.1=20
> on translation of S-VIDs.
>=20
> I guess that this is something we all need to understand, and
> given the answer, it will be possible to follow up with=20
> further more precise questions.
>=20
> If for example the answer on S-VID translation is that it is
> not supported other than at domain borders, then the question=20
> on whether it needs to be done by taking the MAC-address into=20
> consideration or not will have very different meaning.
>=20
> Let agree on getting the liaison out, and then decide on what
> we do next depending on the answer.
>=20
> /Loa
>=20
> Nurit Sprecher wrote:
> > Hi Neil,
> > Thanks for your clarification.
> > Please note that the discussion below relates to the
> liaison that the
> > IETF wants to send to the IEEE in order to understand the standard=20
> > behavior of the Ethernet forwarding behavior. As I
> understand it, Don
> > was concerned that S-VID translation does not preclude the
> forwarding
> > decision which is based on the MAC address. My intention
> was to indicate
> > that for point-to-point VLAN connection (on a link), MAC
> learning is not
> > required by the 802.1Qrev-5 spec and the forwarding
> decision does not
> > rely on the MAC address. This is not a discussion on
> networking but on
> > the standard behavior of the 802.1Q bridges.
> > Regards,
> > Nuritl.
> >=20
> > ________________________________
> >=20
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, September 21, 2006 13:00
> > To: Nurit Sprecher; [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: Proposed liaison response to IEEE
> >=20
> >=20
> > Nurit.....precision is indeed important.  In a co mode
> layer network
> > connections can be p2p or p2mp in nature and each can be
> composed of
> > multiple concatenated subnetwork-connections (ie nodes in THIS layer
> > network) and link-connections......noting that a single p2p
> > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20
> > network is NOT a connection in THAT (ie Ethernet) layer network=20
> > (though it will be supported by a trail which is provided by a=20
> > connection in some lower layer network).
> > =20
> > regards, Neil
> >=20
> > 	-----Original Message-----
> > 	From: [e-mail]
> [mailto:[e-mail]] On
> > Behalf Of Nurit Sprecher
> > 	Sent: 21 September 2006 12:38
> > 	To: Don Fedyk; Adrian Farrel
> > 	Cc: [e-mail]; Wijnen, Bert (Bert);
> [e-mail]; Nurit
> > Sprecher
> > 	Subject: RE: Proposed liaison response to IEEE
> > =09
> > =09
> >=20
> > 	Hi,
> >=20
> > 	=20
> >=20
> > 	I think it is a good idea to send the liaison to the
> IEEE and get
> > once and for all a clear statement that the s-vid translation is
> > supported on each provider bridge port.
> >=20
> > 	=20
> >=20
> > 	In addition, the IEEE has recognized that MAC learning is not
> > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20
> > already includes this extension in section 8.7.
> >=20
> > 	=20
> >=20
> > 	" The Learning Process receives the source MAC
> Addresses and VIDs of
> > received frames from the
> >=20
> > 	Forwarding Process, following the application of the
> ingress rules
> > (8.6.2). It shall create or update a
> >=20
> > 	Dynamic Filtering Entry (8.8.3) that specifies the
> reception Port for
> > the frame's source address and VID, if
> >=20
> > 	and only if the source address is an Individual
> Address, i.e., is not
> > a Group Address, the resulting number of
> >=20
> > 	entries would not exceed the capacity of the Filtering
> Database, and
> > the filtering utility criteria for the
> >=20
> > 	receiving Bridge Port are met."
> >=20
> > 	The enhanced filtering utility criteria "are satisfied
> if at least
> > one VLAN that uses the FID includes the reception Port and at least
> > one other Port with a Port State of Learning or Forwarding in its=20
> > member set, and: a) The operPointToPointMAC parameter is=20
> false for the
> > reception Port; or b) Ingress to the VLAN is permitted
> through a third
> > Port. NOTE -The third port can, but is not required to be in the
> > member set.".
> >=20
> > 	=20
> >=20
> > 	I think it is clearly stated, but if it is required to
> ask the IEEE
> > about the context of forwarding based on a destination MAC,
> I suggest
> > being more precise and specify that we are talking on
> point-to-point
> > connections.
> >=20
> > 	=20
> >=20
> > 	Regards,
> >=20
> > 	Nurit.
> >=20
> > 	=20
> >=20
> > 	-----Original Message-----
> > 	From: [e-mail]
> [mailto:[e-mail]] On
> > Behalf Of Don Fedyk
> > 	Sent: Wednesday, September 20, 2006 23:16
> > 	To: Adrian Farrel; [e-mail]
> > 	Cc: [e-mail]; Wijnen, Bert (Bert)
> > 	Subject: RE: Proposed liaison response to IEEE
> >=20
> > 	=20
> >=20
> > 	Hi Adrian
> >=20
> > 	=20
> >=20
> > 	The Liaison looks good however it does not capture a comment I
> > made.  =20
> >=20
> > 	=20
> >=20
> > 	My understanding of the S-VLAN translation in IEEE
> documents and the
> >=20
> > 	liaison is that the translation is valid in the context
> of forwarding
> >=20
> > 	based on a destination MAC. My interpretation is that V-LAN is
> > optional
> >=20
> > 	MAC is not. If I am correct VLAN translation as
> specified is not
> > equal
> >=20
> > 	to Label switching. The Liaison is clear about not just
> the format of
> >=20
> > 	'packets on the wire' but the relationship to the
> entities such as
> > MAC
> >=20
> > 	relay as well.
> >=20
> > 	=20
> >=20
> > 	I think we should also ask in our liaison for
> clarification if the
> >=20
> > 	S-VLAN translation can be valid by itself i.e. as a
> label agnostic to
> >=20
> > 	the MAC so there is no confusion.
> >=20
> > 	=20
> >=20
> > 	Thanks,
> >=20
> > 	Don
> >=20
> > 	=20
> >=20
> > 	=20
> >=20
> > 	> -----Original Message-----
> >=20
> > 	> From: [e-mail]
> >=20
> > 	> All,
> >=20
> > 	>
> >=20
> > 	> The IETF received an unsolicited liaison on the subject of
> >=20
> > 	> 802.1 Ethernet
> >=20
> > 	>
> >=20
> > 	> You can see the liaison at
> >=20
> > 	> https://datatracker.ietf.org/documents/LIAISON/file358.pdf
> >=20
> > 	>
> >=20
> > 	> The participants on the GELS mailing list have requested that
> >=20
> > 	> we respond to this to clarify an issue.
> >=20
> > 	>
> >=20
> > 	> Here is the draft of a liaison that we proposed to send.
> >=20
> > 	> Please shout at once if you have any concerns with this
> >=20
> > 	> liaison. I intend to ask Bert to send it on Monday of
> next week.
> >=20
> > 	>
> >=20
> > 	> Thanks,
> >=20
> > 	> Adrian
> >=20
> > 	> =3D=3D=3D
> >=20
> > 	> Subject: Response to your liaison "Use of IEEE 802.1Q
> VLAN tags"
> >=20
> > 	>
> >=20
> > 	> Date: Sep 2006
> >=20
> > 	> To: IEEE802.1
> >=20
> > 	>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]
> >=20
> > 	>
> >=20
> > 	> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
> >=20
> > 	>           Adrian Farrel, IETF CCAMP Working Group co-chair
> >=20
> > 	>           Deborah Brungard, IETF CCAMP Working Group co-chair
> >=20
> > 	>
> >=20
> > 	> Cc: Bernard Aboba [e-mail]
> >=20
> > 	>        Ross Callon [e-mail]
> >=20
> > 	>        Bill Fenner [e-mail]
> >=20
> > 	>        CCAMP mailing list [e-mail]
> >=20
> > 	>        GELS mailing list  [e-mail]
> >=20
> > 	>
> >=20
> > 	> Thank you for your very informative and clarifying liaison on
> >=20
> > 	> "Use of IEEE 802.1Q VLAN tags".
> >=20
> > 	>
> >=20
> > 	> We have a question arising from this liaison and our reading
> >=20
> > 	> of the relevant standards documents as follows.
> >=20
> > 	>
> >=20
> > 	> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12
> >=20
> > 	> bit VIDs) is supported at S-tagged service interfaces, as an
> >=20
> > 	> option, by the IEEE Std 802.1ad Provider Bridging amendment
> >=20
> > 	> to IEEE Std 802.1Q."
> >=20
> > 	>
> >=20
> > 	> While this text in itself is clear it leaves open the
> >=20
> > 	> question of whether "S-tagged Service interfaces" is the only
> >=20
> > 	> type of interface where Translation of 802.1Q S-VLAN tags is
> >=20
> > 	> supported.
> >=20
> > 	>
> >=20
> > 	> It is our understanding that IEEE Std 802.1ad does not
> >=20
> > 	> preclude the translation of 802.1Q S-VLAN tags at any
> >=20
> > 	> S-tagged interface. Thus, this translation would be allowed
> >=20
> > 	> at Provider Network Ports, not just at Customer Network Ports.
> >=20
> > 	>
> >=20
> > 	> Can you please confirm whether this is the correct
> >=20
> > 	> interpretation of the IEEE Std 802.1ad amendment to the IEEE
> >=20
> > 	> Std 802.1Q?
> >=20
> > 	>
> >=20
> > 	> Many thanks,
> >=20
> > 	>
> >=20
> > 	> Bert Wijnen, IETF liaison to IEEE 802.1
> >=20
> > 	> Adrian Farrel and Deborah Brungard, CCAMP Working
> Group co-chairs
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	=20
> >=20
> > 	_______________________________________________
> >=20
> > 	gels mailing list
> >=20
> > 	[e-mail]
> >=20
> > 	https://rtg.ietf.org/mailman/listinfo/gels
> >=20
> > 	=20
> >=20
> >=20
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 13:36:00 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 16:34:09 +0200
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: AcbddldP273KLlRIQzqoEjlyRQM/3gABdK1QAAN6wBA=
From: "Nurit Sprecher" <[e-mail]>
To: "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Nurit Sprecher" <[e-mail]>

Out of scope of the discussion of the liaison...

In general, I suggest that before statements on what is applicable and
what is not, the IEEE standards are carefully learnt .......
(1) the enhanced filtering criteria does apply with S-VID
translation.....there is a VLAN classification process at the
ingress........the learning process and the forwarding decisions are
taken on the internal VLAN to which the coming frame was
classified.......the translation operation is performed after the
outgoing port is determined........
(2) If that was true, the entire VLAN concept would loose it
meaning............can not we support broadcasting of unknown frames
correctly with s-vid translation???????????
(3) etc.

Nurit.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Attila Takacs (IJ/ETH)
Sent: Thursday, September 21, 2006 14:59
To: Loa Andersson
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Proposed liaison response to IEEE

Hi all,

I also support the liaison as it is.=20

We will anyhow need to clarify a set of other issues later but these
would now over complicated this liaison.

BTW, I think the enhanced filtering criteria is not applicable if one
applies S-VID translation since the ingress and egress VIDs are
different. An other note: even when the enhanced filtering criteria is
applied the MAC address is considered by forwarding however due to
suppressed MAC learning (no entry for the MAC in FDB) the frame will be
"broadcasted" over the (in this case) only one available egress VLAN
member port.

Regards,
Attila

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Thursday, September 21, 2006 2:03 PM
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Proposed liaison response to IEEE
>=20
> All,
>=20
> there have been a number of correct statements in this short thread.
>=20
> Neil is right (given the layered network model) that Ethernet is a=20
> layer network and as such connectionless and packet oriented.
>=20
> Nurit is right that if you configure a VLAN on only to parts of an=20
> Ethernet bridge the frame will go through without looking at the MAC=20
> address
>=20
> Don is right that the liaison does not capture an earlier comment he=20
> made on the gels-list. Neither does it capture a comment made by=20
> Attila.
>=20
> However, if I understand what is happening here is that we need to=20
> clarify a paragraph in the liaison form the IEEE802.1 on translation=20
> of S-VIDs.
>=20
> I guess that this is something we all need to understand, and given=20
> the answer, it will be possible to follow up with further more precise

> questions.
>=20
> If for example the answer on S-VID translation is that it is not=20
> supported other than at domain borders, then the question on whether=20
> it needs to be done by taking the MAC-address into consideration or=20
> not will have very different meaning.
>=20
> Let agree on getting the liaison out, and then decide on what we do=20
> next depending on the answer.
>=20
> /Loa
>=20
> Nurit Sprecher wrote:
> > Hi Neil,
> > Thanks for your clarification.=20
> > Please note that the discussion below relates to the
> liaison that the
> > IETF wants to send to the IEEE in order to understand the standard=20
> > behavior of the Ethernet forwarding behavior. As I
> understand it, Don
> > was concerned that S-VID translation does not preclude the
> forwarding
> > decision which is based on the MAC address. My intention was to=20
> > indicate that for point-to-point VLAN connection (on a link), MAC=20
> > learning is not required by the 802.1Qrev-5 spec and the forwarding=20
> > decision does not rely on the MAC address. This is not a
> discussion on
> > networking but on the standard behavior of the 802.1Q bridges.
> > Regards,
> > Nuritl.
> >=20
> > ________________________________
> >=20
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, September 21, 2006 13:00
> > To: Nurit Sprecher; [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: Proposed liaison response to IEEE
> >=20
> >=20
> > Nurit.....precision is indeed important.  In a co mode
> layer network
> > connections can be p2p or p2mp in nature and each can be
> composed of
> > multiple concatenated subnetwork-connections (ie nodes in THIS layer
> > network) and link-connections......noting that a single p2p=20
> > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20
> > network is NOT a connection in THAT (ie Ethernet) layer network=20
> > (though it will be supported by a trail which is provided by a=20
> > connection in some lower layer network).
> > =20
> > regards, Neil
> >=20
> > 	-----Original Message-----
> > 	From: [e-mail]
> [mailto:[e-mail]] On
> > Behalf Of Nurit Sprecher
> > 	Sent: 21 September 2006 12:38
> > 	To: Don Fedyk; Adrian Farrel
> > 	Cc: [e-mail]; Wijnen, Bert (Bert);
> [e-mail]; Nurit
> > Sprecher
> > 	Subject: RE: Proposed liaison response to IEEE
> > =09
> > =09
> >=20
> > 	Hi,
> >=20
> > 	=20
> >=20
> > 	I think it is a good idea to send the liaison to the
> IEEE and get
> > once and for all a clear statement that the s-vid translation is=20
> > supported on each provider bridge port.
> >=20
> > 	=20
> >=20
> > 	In addition, the IEEE has recognized that MAC learning is not=20
> > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20
> > already includes this extension in section 8.7.
> >=20
> > 	=20
> >=20
> > 	" The Learning Process receives the source MAC
> Addresses and VIDs of
> > received frames from the
> >=20
> > 	Forwarding Process, following the application of the
> ingress rules
> > (8.6.2). It shall create or update a
> >=20
> > 	Dynamic Filtering Entry (8.8.3) that specifies the
> reception Port for
> > the frame's source address and VID, if
> >=20
> > 	and only if the source address is an Individual
> Address, i.e., is not
> > a Group Address, the resulting number of
> >=20
> > 	entries would not exceed the capacity of the Filtering
> Database, and
> > the filtering utility criteria for the
> >=20
> > 	receiving Bridge Port are met."
> >=20
> > 	The enhanced filtering utility criteria "are satisfied
> if at least
> > one VLAN that uses the FID includes the reception Port and at least=20
> > one other Port with a Port State of Learning or Forwarding in its=20
> > member set, and: a) The operPointToPointMAC parameter is
> false for the
> > reception Port; or b) Ingress to the VLAN is permitted
> through a third
> > Port. NOTE -The third port can, but is not required to be in the=20
> > member set.".
> >=20
> > 	=20
> >=20
> > 	I think it is clearly stated, but if it is required to
> ask the IEEE
> > about the context of forwarding based on a destination MAC,
> I suggest
> > being more precise and specify that we are talking on
> point-to-point
> > connections.
> >=20
> > 	=20
> >=20
> > 	Regards,
> >=20
> > 	Nurit.
> >=20
> > 	=20
> >=20
> > 	-----Original Message-----
> > 	From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Don Fedyk
> > 	Sent: Wednesday, September 20, 2006 23:16
> > 	To: Adrian Farrel; [e-mail]
> > 	Cc: [e-mail]; Wijnen, Bert (Bert)
> > 	Subject: RE: Proposed liaison response to IEEE
> >=20
> > 	=20
> >=20
> > 	Hi Adrian
> >=20
> > 	=20
> >=20
> > 	The Liaison looks good however it does not capture a comment I
> > made.  =20
> >=20
> > 	=20
> >=20
> > 	My understanding of the S-VLAN translation in IEEE
> documents and the
> >=20
> > 	liaison is that the translation is valid in the context
> of forwarding
> >=20
> > 	based on a destination MAC. My interpretation is that V-LAN is=20
> > optional
> >=20
> > 	MAC is not. If I am correct VLAN translation as
> specified is not
> > equal
> >=20
> > 	to Label switching. The Liaison is clear about not just
> the format of
> >=20
> > 	'packets on the wire' but the relationship to the
> entities such as
> > MAC
> >=20
> > 	relay as well. =20
> >=20
> > 	=20
> >=20
> > 	I think we should also ask in our liaison for
> clarification if the
> >=20
> > 	S-VLAN translation can be valid by itself i.e. as a
> label agnostic to
> >=20
> > 	the MAC so there is no confusion.
> >=20
> > 	=20
> >=20
> > 	Thanks,
> >=20
> > 	Don
> >=20
> > 	=20
> >=20
> > 	=20
> >=20
> > 	> -----Original Message-----
> >=20
> > 	> From: [e-mail]
> >=20
> > 	> All,
> >=20
> > 	>
> >=20
> > 	> The IETF received an unsolicited liaison on the subject of
> >=20
> > 	> 802.1 Ethernet
> >=20
> > 	>
> >=20
> > 	> You can see the liaison at
> >=20
> > 	> https://datatracker.ietf.org/documents/LIAISON/file358.pdf
> >=20
> > 	>
> >=20
> > 	> The participants on the GELS mailing list have requested that
> >=20
> > 	> we respond to this to clarify an issue.
> >=20
> > 	>
> >=20
> > 	> Here is the draft of a liaison that we proposed to send.=20
> >=20
> > 	> Please shout at once if you have any concerns with this
> >=20
> > 	> liaison. I intend to ask Bert to send it on Monday of
> next week.
> >=20
> > 	>
> >=20
> > 	> Thanks,
> >=20
> > 	> Adrian
> >=20
> > 	> =3D=3D=3D
> >=20
> > 	> Subject: Response to your liaison "Use of IEEE 802.1Q
> VLAN tags"
> >=20
> > 	>
> >=20
> > 	> Date: Sep 2006
> >=20
> > 	> To: IEEE802.1
> >=20
> > 	>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]
> >=20
> > 	>
> >=20
> > 	> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
> >=20
> > 	>           Adrian Farrel, IETF CCAMP Working Group co-chair
> >=20
> > 	>           Deborah Brungard, IETF CCAMP Working Group co-chair
> >=20
> > 	>
> >=20
> > 	> Cc: Bernard Aboba [e-mail]
> >=20
> > 	>        Ross Callon [e-mail]
> >=20
> > 	>        Bill Fenner [e-mail]
> >=20
> > 	>        CCAMP mailing list [e-mail]
> >=20
> > 	>        GELS mailing list  [e-mail]
> >=20
> > 	>
> >=20
> > 	> Thank you for your very informative and clarifying liaison on
> >=20
> > 	> "Use of IEEE 802.1Q VLAN tags".
> >=20
> > 	>
> >=20
> > 	> We have a question arising from this liaison and our reading
> >=20
> > 	> of the relevant standards documents as follows.
> >=20
> > 	>
> >=20
> > 	> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12
> >=20
> > 	> bit VIDs) is supported at S-tagged service interfaces, as an
> >=20
> > 	> option, by the IEEE Std 802.1ad Provider Bridging amendment
> >=20
> > 	> to IEEE Std 802.1Q."
> >=20
> > 	>
> >=20
> > 	> While this text in itself is clear it leaves open the
> >=20
> > 	> question of whether "S-tagged Service interfaces" is the only
> >=20
> > 	> type of interface where Translation of 802.1Q S-VLAN tags is
> >=20
> > 	> supported.
> >=20
> > 	>
> >=20
> > 	> It is our understanding that IEEE Std 802.1ad does not
> >=20
> > 	> preclude the translation of 802.1Q S-VLAN tags at any
> >=20
> > 	> S-tagged interface. Thus, this translation would be allowed
> >=20
> > 	> at Provider Network Ports, not just at Customer Network Ports.
> >=20
> > 	>
> >=20
> > 	> Can you please confirm whether this is the correct
> >=20
> > 	> interpretation of the IEEE Std 802.1ad amendment to the IEEE
> >=20
> > 	> Std 802.1Q?
> >=20
> > 	>
> >=20
> > 	> Many thanks,
> >=20
> > 	>
> >=20
> > 	> Bert Wijnen, IETF liaison to IEEE 802.1
> >=20
> > 	> Adrian Farrel and Deborah Brungard, CCAMP Working
> Group co-chairs
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	=20
> >=20
> > 	_______________________________________________
> >=20
> > 	gels mailing list
> >=20
> > 	[e-mail]
> >=20
> > 	https://rtg.ietf.org/mailman/listinfo/gels
> >=20
> > 	=20
> >=20
> >=20
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]=20
> _______________________________________________
> gels mailing list
> [e-mail]
> https://rtg.ietf.org/mailman/listinfo/gels
>=20

_______________________________________________
gels mailing list
[e-mail]
https://rtg.ietf.org/mailman/listinfo/gels





Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 12:59:58 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 14:59:15 +0200
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: AcbddldP273KLlRIQzqoEjlyRQM/3gABdK1Q
From: "Attila Takacs \(IJ/ETH\)" <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi all,

I also support the liaison as it is.=20

We will anyhow need to clarify a set of other issues later but these
would now over complicated this liaison.

BTW, I think the enhanced filtering criteria is not applicable if one
applies S-VID translation since the ingress and egress VIDs are
different. An other note: even when the enhanced filtering criteria is
applied the MAC address is considered by forwarding however due to
suppressed MAC learning (no entry for the MAC in FDB) the frame will be
"broadcasted" over the (in this case) only one available egress VLAN
member port.

Regards,
Attila

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Thursday, September 21, 2006 2:03 PM
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Proposed liaison response to IEEE
>=20
> All,
>=20
> there have been a number of correct statements in this short thread.
>=20
> Neil is right (given the layered network model) that Ethernet=20
> is a layer network and as such connectionless and packet oriented.
>=20
> Nurit is right that if you configure a VLAN on only to parts=20
> of an Ethernet bridge the frame will go through without=20
> looking at the MAC address
>=20
> Don is right that the liaison does not capture an earlier=20
> comment he made on the gels-list. Neither does it capture a=20
> comment made by Attila.
>=20
> However, if I understand what is happening here is that we=20
> need to clarify a paragraph in the liaison form the IEEE802.1=20
> on translation of S-VIDs.
>=20
> I guess that this is something we all need to understand, and=20
> given the answer, it will be possible to follow up with=20
> further more precise questions.
>=20
> If for example the answer on S-VID translation is that it is=20
> not supported other than at domain borders, then the question=20
> on whether it needs to be done by taking the MAC-address into=20
> consideration or not will have very different meaning.
>=20
> Let agree on getting the liaison out, and then decide on what=20
> we do next depending on the answer.
>=20
> /Loa
>=20
> Nurit Sprecher wrote:
> > Hi Neil,
> > Thanks for your clarification.=20
> > Please note that the discussion below relates to the=20
> liaison that the=20
> > IETF wants to send to the IEEE in order to understand the standard=20
> > behavior of the Ethernet forwarding behavior. As I=20
> understand it, Don=20
> > was concerned that S-VID translation does not preclude the=20
> forwarding=20
> > decision which is based on the MAC address. My intention was to=20
> > indicate that for point-to-point VLAN connection (on a link), MAC=20
> > learning is not required by the 802.1Qrev-5 spec and the forwarding=20
> > decision does not rely on the MAC address. This is not a=20
> discussion on=20
> > networking but on the standard behavior of the 802.1Q bridges.
> > Regards,
> > Nuritl.
> >=20
> > ________________________________
> >=20
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, September 21, 2006 13:00
> > To: Nurit Sprecher; [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: Proposed liaison response to IEEE
> >=20
> >=20
> > Nurit.....precision is indeed important.  In a co mode=20
> layer network=20
> > connections can be p2p or p2mp in nature and each can be=20
> composed of=20
> > multiple concatenated subnetwork-connections (ie nodes in THIS layer
> > network) and link-connections......noting that a single p2p=20
> > link-connection hop between 2 bridges in a cl-ps Ethernet layer=20
> > network is NOT a connection in THAT (ie Ethernet) layer network=20
> > (though it will be supported by a trail which is provided by a=20
> > connection in some lower layer network).
> > =20
> > regards, Neil
> >=20
> > 	-----Original Message-----
> > 	From: [e-mail]=20
> [mailto:[e-mail]] On=20
> > Behalf Of Nurit Sprecher
> > 	Sent: 21 September 2006 12:38
> > 	To: Don Fedyk; Adrian Farrel
> > 	Cc: [e-mail]; Wijnen, Bert (Bert);=20
> [e-mail]; Nurit=20
> > Sprecher
> > 	Subject: RE: Proposed liaison response to IEEE
> > =09
> > =09
> >=20
> > 	Hi,
> >=20
> > 	=20
> >=20
> > 	I think it is a good idea to send the liaison to the=20
> IEEE and get=20
> > once and for all a clear statement that the s-vid translation is=20
> > supported on each provider bridge port.
> >=20
> > 	=20
> >=20
> > 	In addition, the IEEE has recognized that MAC learning is not=20
> > required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20
> > already includes this extension in section 8.7.
> >=20
> > 	=20
> >=20
> > 	" The Learning Process receives the source MAC=20
> Addresses and VIDs of=20
> > received frames from the
> >=20
> > 	Forwarding Process, following the application of the=20
> ingress rules=20
> > (8.6.2). It shall create or update a
> >=20
> > 	Dynamic Filtering Entry (8.8.3) that specifies the=20
> reception Port for=20
> > the frame's source address and VID, if
> >=20
> > 	and only if the source address is an Individual=20
> Address, i.e., is not=20
> > a Group Address, the resulting number of
> >=20
> > 	entries would not exceed the capacity of the Filtering=20
> Database, and=20
> > the filtering utility criteria for the
> >=20
> > 	receiving Bridge Port are met."
> >=20
> > 	The enhanced filtering utility criteria "are satisfied=20
> if at least=20
> > one VLAN that uses the FID includes the reception Port and at least=20
> > one other Port with a Port State of Learning or Forwarding in its=20
> > member set, and: a) The operPointToPointMAC parameter is=20
> false for the=20
> > reception Port; or b) Ingress to the VLAN is permitted=20
> through a third=20
> > Port. NOTE -The third port can, but is not required to be in the=20
> > member set.".
> >=20
> > 	=20
> >=20
> > 	I think it is clearly stated, but if it is required to=20
> ask the IEEE=20
> > about the context of forwarding based on a destination MAC,=20
> I suggest=20
> > being more precise and specify that we are talking on=20
> point-to-point=20
> > connections.
> >=20
> > 	=20
> >=20
> > 	Regards,
> >=20
> > 	Nurit.
> >=20
> > 	=20
> >=20
> > 	-----Original Message-----
> > 	From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Don Fedyk
> > 	Sent: Wednesday, September 20, 2006 23:16
> > 	To: Adrian Farrel; [e-mail]
> > 	Cc: [e-mail]; Wijnen, Bert (Bert)
> > 	Subject: RE: Proposed liaison response to IEEE
> >=20
> > 	=20
> >=20
> > 	Hi Adrian
> >=20
> > 	=20
> >=20
> > 	The Liaison looks good however it does not capture a comment I
> > made.  =20
> >=20
> > 	=20
> >=20
> > 	My understanding of the S-VLAN translation in IEEE=20
> documents and the
> >=20
> > 	liaison is that the translation is valid in the context=20
> of forwarding
> >=20
> > 	based on a destination MAC. My interpretation is that V-LAN is=20
> > optional
> >=20
> > 	MAC is not. If I am correct VLAN translation as=20
> specified is not=20
> > equal
> >=20
> > 	to Label switching. The Liaison is clear about not just=20
> the format of
> >=20
> > 	'packets on the wire' but the relationship to the=20
> entities such as=20
> > MAC
> >=20
> > 	relay as well. =20
> >=20
> > 	=20
> >=20
> > 	I think we should also ask in our liaison for=20
> clarification if the
> >=20
> > 	S-VLAN translation can be valid by itself i.e. as a=20
> label agnostic to
> >=20
> > 	the MAC so there is no confusion.
> >=20
> > 	=20
> >=20
> > 	Thanks,
> >=20
> > 	Don
> >=20
> > 	=20
> >=20
> > 	=20
> >=20
> > 	> -----Original Message-----
> >=20
> > 	> From: [e-mail]
> >=20
> > 	> All,
> >=20
> > 	>
> >=20
> > 	> The IETF received an unsolicited liaison on the subject of
> >=20
> > 	> 802.1 Ethernet
> >=20
> > 	>
> >=20
> > 	> You can see the liaison at
> >=20
> > 	> https://datatracker.ietf.org/documents/LIAISON/file358.pdf
> >=20
> > 	>
> >=20
> > 	> The participants on the GELS mailing list have requested that
> >=20
> > 	> we respond to this to clarify an issue.
> >=20
> > 	>
> >=20
> > 	> Here is the draft of a liaison that we proposed to send.=20
> >=20
> > 	> Please shout at once if you have any concerns with this
> >=20
> > 	> liaison. I intend to ask Bert to send it on Monday of=20
> next week.
> >=20
> > 	>
> >=20
> > 	> Thanks,
> >=20
> > 	> Adrian
> >=20
> > 	> =3D=3D=3D
> >=20
> > 	> Subject: Response to your liaison "Use of IEEE 802.1Q=20
> VLAN tags"
> >=20
> > 	>
> >=20
> > 	> Date: Sep 2006
> >=20
> > 	> To: IEEE802.1
> >=20
> > 	>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]
> >=20
> > 	>
> >=20
> > 	> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
> >=20
> > 	>           Adrian Farrel, IETF CCAMP Working Group co-chair
> >=20
> > 	>           Deborah Brungard, IETF CCAMP Working Group co-chair
> >=20
> > 	>
> >=20
> > 	> Cc: Bernard Aboba [e-mail]
> >=20
> > 	>        Ross Callon [e-mail]
> >=20
> > 	>        Bill Fenner [e-mail]
> >=20
> > 	>        CCAMP mailing list [e-mail]
> >=20
> > 	>        GELS mailing list  [e-mail]
> >=20
> > 	>
> >=20
> > 	> Thank you for your very informative and clarifying liaison on
> >=20
> > 	> "Use of IEEE 802.1Q VLAN tags".
> >=20
> > 	>
> >=20
> > 	> We have a question arising from this liaison and our reading
> >=20
> > 	> of the relevant standards documents as follows.
> >=20
> > 	>
> >=20
> > 	> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12
> >=20
> > 	> bit VIDs) is supported at S-tagged service interfaces, as an
> >=20
> > 	> option, by the IEEE Std 802.1ad Provider Bridging amendment
> >=20
> > 	> to IEEE Std 802.1Q."
> >=20
> > 	>
> >=20
> > 	> While this text in itself is clear it leaves open the
> >=20
> > 	> question of whether "S-tagged Service interfaces" is the only
> >=20
> > 	> type of interface where Translation of 802.1Q S-VLAN tags is
> >=20
> > 	> supported.
> >=20
> > 	>
> >=20
> > 	> It is our understanding that IEEE Std 802.1ad does not
> >=20
> > 	> preclude the translation of 802.1Q S-VLAN tags at any
> >=20
> > 	> S-tagged interface. Thus, this translation would be allowed
> >=20
> > 	> at Provider Network Ports, not just at Customer Network Ports.
> >=20
> > 	>
> >=20
> > 	> Can you please confirm whether this is the correct
> >=20
> > 	> interpretation of the IEEE Std 802.1ad amendment to the IEEE
> >=20
> > 	> Std 802.1Q?
> >=20
> > 	>
> >=20
> > 	> Many thanks,
> >=20
> > 	>
> >=20
> > 	> Bert Wijnen, IETF liaison to IEEE 802.1
> >=20
> > 	> Adrian Farrel and Deborah Brungard, CCAMP Working=20
> Group co-chairs
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	>
> >=20
> > 	=20
> >=20
> > 	_______________________________________________
> >=20
> > 	gels mailing list
> >=20
> > 	[e-mail]
> >=20
> > 	https://rtg.ietf.org/mailman/listinfo/gels
> >=20
> > 	=20
> >=20
> >=20
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]=20
> _______________________________________________
> gels mailing list
> [e-mail]
> https://rtg.ietf.org/mailman/listinfo/gels
>=20



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 12:32:39 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-36-146102614
Message-Id: <[e-mail]>
Cc: <[e-mail]>, "Ross Callon" <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01
Date: Thu, 21 Sep 2006 08:32:08 -0400
To: "Adrian Farrel" <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=32785; t=1158841933; x=1159705933; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:JP=20Vasseur=20<[e-mail]> |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01 |To:=22Adrian=20Farrel=22=20<[e-mail]>; X=v=3Dcisco.com=3B=20h=3DMEBChjdj4/CIq2s4jZyCacxjCHY=3D; b=sXj5s6poseORm4S1h5YvITMwou/LKpYraejs7ohNNUIhXCNhklGdGcrodhrzcKQ4vJxkPtgd kD8SKBPcfD7rAs1u+sPkPgec9jn8k4gmeMRMQFhNZFSA89AEcESREZE6;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; );

--Apple-Mail-36-146102614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	delsp=yes;
	format=flowed

Hi Adrian,

On Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote:

> Hi,
>
> We held an additional last call for this draft in the IGP working =20
> groups and received some further comments that JP has just =20
> addressed in a new revision.
>
> We have also received some comments from a review in the Routing =20
> Directorate that I am pr=E9cising below. JP, authors: please look =20
> through these and let us know your proposals for dealing with them.
>

Sure, in line.

> Thanks,
> Adrian
>
> =3D=3D=3D
>
> 1) The Tail-end name field facilitates LSP identification. Is this =20
> a new form of LSP identification?
> If it is not new, then there should be a reference to RFC3209 and a =20=

> statement of which RFC3209 fields are mapped to this IGP field.
> If it is not new then there is a significant concern that a new =20
> identification is being introduced when it is not needed.

As indicated in the document the string refers to a "Tail-end" name, =20
not an TE LSP name: thus it does not replace the session name of the =20
SESSION-ATTRIBUTE object defined in RFC3209.

>
> 2) The document mentions that the number of mesh groups is limited =20
> but potentially (depending on encoding) provides for binary =20
> encoding for
> 2^32-1 groups (although this might be constrained by OSPF's limit =20
> of a TLV size to 2^16 bytes.
> The document (and the authors) state that scaling of these =20
> extensions is not an issue because only a small number of mesh =20
> groups are likely to be in existence in a network, and any one =20
> router is unlikely to participate in more than a very few.
> There are two concerns:
> a) Whenever we say that something in the Internet is limited, =20
> history usually proves us wrong.

And that's undoubtedly a good news :-)

> Indeed, there is already a
> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a =20
> similar mechanism for a problem that would have far more groups.

Two comments:
- Mesh groups are used to set up TE LSP meshes. If we consider let =20
say 10 meshes comprising 100 routers each, that gives us 99,000 TE =20
LSPs. One can easily see that the number of meshes is unlikely to =20
explode in a foreseeable future. If it turns out to be the case, =20
we'll have other scalability issues to fix before any potential with =20
the IGP.
- More importantly, the dynamics of joining a TE mesh is such that =20
IGP updates are used to advertise to TE mesh group membership change =20
(join or prune), which are indeed expected to be very unfrequent.

> b) The I-D does not itself impose any reasonable limits on the =20
> number of groups with the potential for a single router (by =20
> misconfiguration, design, or malice) advertising a very large =20
> number of groups.
> Thus, it appears that the scaling concerns are not properly =20
> addressed in this I-D.
>

Not sure to see the point here. If indeed, a large number of TE MESH =20
GROUPs were advertised, this would not impact the other LSRs since =20
they would not create any new TE LSPs trying to join the new TE-MESH-=20
GROUP. In term of amount of flooded information, this should not be a =20=

concern either (handled by routing). We clarified this in the =20
security section.

> 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL =20
> and must at most appear once in a OSPF Router Information LSA or =20
> ISIS Router Capability TLV." but for addition/removal it mentions =20
> "conversely, if the LSR leaves a mesh-group the corresponding entry =20=

> will be removed from the TE-MESH-GROUP TLV."
> What are these "entries" referring to - that there is a top-level =20
> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions =20=

> "No sub-TLV is currently defined for the TE-mesh-group TLV") ?
>
> AF>> My comment on this is that the definition of the TLVs seems =20
> unclear.
> AF>> =46rom figure 2, it appears that some additional information can =
be
> AF>> present in the TLV after the fields listed, and (reading =20
> between the
> AF>> lines) it would appear that this additional information is a =20
> series of
> AF>> repeats of the set of fields to define multiple mesh groups.
> AF>> This could usefully be clarified considerably.
>

You're absolutely right. The figures have been modified:

(example show below):

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      mesh-group-number 1                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Tail-end IPv4 address 1                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Name length  |               Tail-end name 1                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                                                               /=20=

/
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      mesh-group-number n                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Tail-end IPv4 address n                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Name length  |               Tail-end name n                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)


> AF>>
> AF>> But it is now unclear to me whether a single router can be a =20
> member
> AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be
> AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one
> AF>> IPv6) are prohibited.

OK the text requires some clarification. What is prohibited is to =20
have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is =20
permitted. New proposed text to clarify:

The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and =20
one IPv6 instance MUST appear in a OSPF Router Information LSA or =20
ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or =20
IPv6) occurs more than once within the OSPF Router Information LSA, =20
only the first instance is processed, subsequent TLV(s) will be =20
silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 =20
or IPv6) occurs more than once within the ISIS Router capability TLV, =20=

only the first instance is processed, subsequent TLV(s) will be =20
silently ignored.

>
> 4) Small terminology issue in section 5.1 it says: "Note that both =20
> operations can be performed in the context of a single refresh."
> This is not a refresh. It is a trigger/update. A better term for =20
> OSPF would be "LSA origination".
>

OK fixed (I used the term "Update"), thanks.

> 5) Please state the applicability to OSPF v2 and or v3. Note that =20
> the Router_Cap document covers both v2 and v3

Indeed, Thanks for the comments.  The OSPFv3 aspects have been =20
incorporated. Here is the new text:

    The TE-MESH-GROUP TLV is advertised within an OSPF Router =20
Information
    opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328])
    and within a new LSA (Router Information LSA) for OSPFv3 =20
([RFC2740]).

...

    As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the
    flooding scope of the Router Information LSA is determined by the =20=

LSA
    Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3.

    For OSPFv2 Router Information opaque LSA:

    - Link-local scope: type 9;

    - Area-local scope: type 10;

    - Routing-domain scope: type 11.  In this case, the flooding =20
scope is
    equivalent to the Type 5 LSA flooding scope.

    For OSPFv3 Router Information LSA:

    - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2
    bits cleared;

    - Area-local scope: OSPFV3 Router Information LSA with the S1 bit =20=

set
    and the S2 bit cleared;

    - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit
    cleared and the S2 bit set.

    A router may generate multiple OSPF Router Information LSAs with
    different flooding scopes.  The TE-MESH-GROUP TLV may be advertised
    within an Area-local or Routing-domain scope Router Information LSA
    depending on the MPLS TE mesh group profile:

    - If the MPLS TE mesh-group is contained within a single area (all
    the LSRs of the mesh-group are contained within a single area), the
    TE-MESH-GROUP TLV MUST be generated within an Area-local Router
    Information LSA;

    - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh-
    group TLV MUST be generated within a Routing-domain scope router
    information LSA.

>
> 6) The term "fairly static" at the end of section 5.1 is =20
> meaningless without some relative context.
> Presumably this relates to the number times an LSR joins or leaves =20
> a mesh group over time.
> Is it intended to be relative to the IGP refresh period?
> Please clarify in an objective rather than a subjective way.
>

Right, this requires clarification. Here is the new text: Moreover, =20
TE mesh-group membership should not change frequently: each time an =20
LSR joins or leaves a new TE mesh-group.

I guess that this is sufficiently explicit: it is a well-known fact =20
that LSRs are infrequently added or removed to a TE mesh.

> 7) The security section (section 8) is inadequate and will =20
> undoubtedly be rejected by the security ADs. At the very least, the =20=

> I-D needs a paragraph (i.e. more than one or two lines) explaining =20
> why there are no new security considerations. But what would be the =20=

> impact of adding false mesh groups to a TLV? Is there anything =20
> (dangerous) that can be learned about the network by inspecting =20
> mesh group TLVs?
>

The following section has been added:

    No new security issues are raised in this document.  Any new =20
security
    issues raised by the procedures in this document depend upon the
    opportunity for LSAs/LSPs to be snooped, the ease/difficulty of =20
which
    has not been altered.  Security considerations are covered in
    [RFC2328] and [RFC2740] for the base OSPF protocol and in [RFC1194]
    for IS-IS.  As the LSPs may now contain additional information
    regarding router capabilities, this new information would also =20
become
    available.  Note that intentional or unintentional advertisement of
    "fake" TE Mesh Groups by an LSR A does not have any impact on other
    LSRs since an LSR B would only try to signal a TE LSP torward that
    advertizing LSR A to join the advertized TE Mesh TE Group if and =20
only
    if such TE Mesh Group is also locally configured on LSR B.

+ new references added.


Does that address the comments ?

Thanks.

JP.=

--Apple-Mail-36-146102614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Hi Adrian,<DIV><BR><DIV><DIV>On =
Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Hi,</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">We held an additional last call =
for this draft in the IGP working groups and received some further =
comments that JP has just addressed in a new revision.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">We have =
also received some comments from a review in the Routing Directorate =
that I am pr=E9cising below. JP, authors: please look through these and =
let us know your proposals for dealing with them.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Sure, in =
line.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Thanks,</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Adrian</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">=3D=3D=3D</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1) The =
Tail-end name field facilitates LSP identification. Is this a new form =
of LSP identification?</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">If it is not new, then =
there should be a reference to RFC3209 and a statement of which RFC3209 =
fields are mapped to this IGP field.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">If it is not =
new then there is a significant concern that a new identification is =
being introduced when it is not needed.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>As indicated in the =
document the string refers to a "Tail-end" name, not an TE LSP name: =
thus it does not replace the session name of the SESSION-ATTRIBUTE =
object defined in RFC3209.=A0</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2) The =
document mentions that the number of mesh groups is limited but =
potentially (depending on encoding) provides for binary encoding =
for</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">2^32-1 groups (although this =
might be constrained by OSPF's limit of a TLV size to 2^16 =
bytes.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The document (and the authors) =
state that scaling of these extensions is not an issue because only a =
small number of mesh groups are likely to be in existence in a network, =
and any one router is unlikely to participate in more than a very =
few.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">There are two =
concerns:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">a) Whenever we say that =
something in the Internet is limited, history usually proves us wrong. =
<BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>And that's undoubtedly a =
good news :-)=A0</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Indeed, there is already a</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) =
that uses a similar mechanism for a problem that would have far more =
groups.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Two comments:</DIV><DIV>- =
Mesh groups are used to set up TE LSP meshes. If we consider let say 10 =
meshes comprising 100 routers each, that gives us 99,000 TE LSPs. One =
can easily see that the number of meshes is unlikely to explode in =
a=A0foreseeable future. If it turns out to be the case, we'll have other =
scalability issues to fix before any potential with the IGP.</DIV><DIV>- =
More importantly, the dynamics of joining a TE mesh is such that IGP =
updates are used to advertise to TE mesh group membership change (join =
or prune), which are indeed expected to be very =
unfrequent.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">b) The =
I-D does not itself impose any reasonable limits on the number of groups =
with the potential for a single router (by misconfiguration, design, or =
malice) advertising a very large number of groups.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Thus, it appears that the scaling concerns are not =
properly addressed in this I-D.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Not sure to see the point =
here. If indeed, a large number of TE MESH GROUPs were advertised, this =
would not impact the other LSRs since they would not create any new TE =
LSPs trying to join the new TE-MESH-GROUP. In term of amount of flooded =
information, this should not be a concern either (handled by routing). =
We clarified this in the security section.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">3) The document mentions that "The TE-MESH-GROUP TLV =
is OPTIONAL and must at most appear once in a OSPF Router Information =
LSA or ISIS Router Capability TLV." but for addition/removal it mentions =
"conversely, if the LSR leaves a mesh-group the corresponding entry will =
be removed from the TE-MESH-GROUP TLV."</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">What are =
these "entries" referring to - that there is a top-level TE-MESH-GROUP =
TLV with multiple sub-TLVs (but the document mentions "No sub-TLV is =
currently defined for the TE-mesh-group TLV") ?</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">AF&gt;&gt; My comment on this is that the definition of the TLVs seems =
unclear.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; =46rom figure 2, it =
appears that some additional information can be</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">AF&gt;&gt; present in the TLV after the fields =
listed, and (reading between the</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; =
lines) it would appear that this additional information is a series =
of</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; ">AF&gt;&gt; repeats of the set of fields to =
define multiple mesh groups.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; =
This could usefully be clarified considerably.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>You're absolutely right. =
The figures have been modified:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(example show =
below):</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>=A0 =A0=
 =A0=A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
mesh-group-number 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
|</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Tail-end IPv4 =
address 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V>=A0 =A0 =A0 |=A0 Name length=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =
Tail-end name 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V>=A0 =A0=A0 //=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =
//</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
mesh-group-number n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
|</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Tail-end IPv4 =
address n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |</DIV><DIV>=A0 =A0=A0 =
=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV>=
<DIV>=A0 =A0 =A0 |=A0 Name length=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =
Tail-end name n=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |</DIV><DIV>=A0 =A0 =A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</DIV><DI=
V><BR class=3D"khtml-block-placeholder"></DIV><DIV>=A0 =A0 =A0 =A0 =A0 =
Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type=3D"cite"><DIV=
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">AF&gt;&gt;</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; =
But it is now unclear to me whether a single router can be a =
member</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; of IPv4 an IPv6 mesh =
groups. It would seem that these cannot be</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">AF&gt;&gt; mixed within a single TLV, and multiple TLVs (one IPv4 and =
one</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">AF&gt;&gt; IPv6) are =
prohibited.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OK the text requires some =
clarification. What is prohibited is to have two IPv4 sub-TLV or two =
IPv6 sub-TLV but one of each is permitted. New proposed text to =
clarify:</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><I>The=
 TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and one =
IPv6 instance MUST appear in a OSPF Router Information LSA or ISIS =
Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) =
occurs more than once within the OSPF Router Information LSA, only the =
first instance is processed, subsequent TLV(s) will be silently ignored. =
Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 or IPv6) occurs more =
than once within the ISIS Router capability TLV, only the first instance =
is processed, subsequent TLV(s) will be silently =
ignored.</I></DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">4) Small =
terminology issue in section 5.1 it says: "Note that both operations can =
be performed in the context of a single refresh."</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">This is not a refresh. It is a trigger/update. A =
better term for OSPF would be "LSA origination".</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>OK fixed (I used the term =
"Update"), thanks.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">5) =
Please state the applicability to OSPF v2 and or v3. Note that the =
Router_Cap document covers both v2 and v3</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Indeed, Thanks for the =
comments.=A0 The OSPFv3 aspects have been incorporated. Here is the new =
text:</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><I>=A0 =
=A0The TE-MESH-GROUP TLV is advertised within an OSPF Router =
Information</I></DIV><DIV><I>=A0=A0 opaque LSA (opaque type of 4, opaque =
ID of 0) for OSPFv2 ([RFC2328])</I></DIV><DIV><I>=A0=A0 and within a new =
LSA (Router Information LSA) for OSPFv3 =
([RFC2740]).</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>...</I></DIV><DIV><I><=
BR class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0 =A0As defined =
in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, =
the</I></DIV><DIV><I>=A0=A0 flooding scope of the Router Information LSA =
is determined by the LSA</I></DIV><DIV><I>=A0=A0 Opaque type for OSPFv2 =
and the values of the S1/S2 bits for OSPFv3.</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 For OSPFv2 =
Router Information opaque LSA:</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - Link-local =
scope: type 9;</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - Area-local =
scope: type 10;</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - =
Routing-domain scope: type 11.=A0 In this case, the flooding scope =
is</I></DIV><DIV><I>=A0=A0 equivalent to the Type 5 LSA flooding =
scope.</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 For OSPFv3 =
Router Information LSA:</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - Link-local =
scope: OSPFV3 Router Information LSA with the S1 and =
S2</I></DIV><DIV><I>=A0=A0 bits cleared;</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - Area-local =
scope: OSPFV3 Router Information LSA with the S1 bit =
set</I></DIV><DIV><I>=A0=A0 and the S2 bit cleared;</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - =
Routing-domain scope: OSPFv3 Router Information LSA with S1 =
bit</I></DIV><DIV><I>=A0 =A0cleared and the S2 bit =
set.</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 A router may =
generate multiple OSPF Router Information LSAs with</I></DIV><DIV><I>=A0=A0=
 different flooding scopes.=A0 The TE-MESH-GROUP TLV may be =
advertised</I></DIV><DIV><I>=A0=A0 within an Area-local or =
Routing-domain scope Router Information LSA</I></DIV><DIV><I>=A0=A0 =
depending on the MPLS TE mesh group profile:</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - If the MPLS =
TE mesh-group is contained within a single area (all</I></DIV><DIV><I>=A0=A0=
 the LSRs of the mesh-group are contained within a single area), =
the</I></DIV><DIV><I>=A0=A0 TE-MESH-GROUP TLV MUST be generated within =
an Area-local Router</I></DIV><DIV><I>=A0=A0 Information =
LSA;</I></DIV><DIV><I><BR =
class=3D"khtml-block-placeholder"></I></DIV><DIV><I>=A0=A0 - If the MPLS =
TE mesh-group spans multiple OSPF areas, the TE =
mesh-</I></DIV><DIV><I>=A0=A0 group TLV MUST be generated within a =
Routing-domain scope router</I></DIV><DIV><I>=A0=A0 information =
LSA.</I></DIV><I><BR></I><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">6) The =
term "fairly static" at the end of section 5.1 is meaningless without =
some relative context.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">Presumably this relates to =
the number times an LSR joins or leaves a mesh group over =
time.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Is it intended to be relative to =
the IGP refresh period?</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Please =
clarify in an objective rather than a subjective way.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Right, this requires =
clarification. Here is the new text:=A0<I>Moreover, TE mesh-group =
membership should not change frequently: each time an LSR joins or =
leaves a new TE mesh-group.=A0</I></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I guess that this is =
sufficiently explicit: it is a well-known fact that LSRs =
are=A0infrequently added or removed to a TE mesh.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">7) The security section (section 8) is inadequate =
and will undoubtedly be rejected by the security ADs. At the very least, =
the I-D needs a paragraph (i.e. more than one or two lines) explaining =
why there are no new security considerations. But what would be the =
impact of adding false mesh groups to a TLV? Is there anything =
(dangerous) that can be learned about the network by inspecting mesh =
group TLVs?</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE></DIV><BR></DIV><DIV>The following section has been =
added:</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><SPAN =
class=3D"Apple-style-span">=A0 =A0<I>No new security issues are raised =
in this document.=A0 Any new security</I></SPAN></DIV><DIV><I>=A0=A0 =
issues raised by the procedures in this document depend upon =
the</I></DIV><DIV><I>=A0=A0 opportunity for LSAs/LSPs to be snooped, the =
ease/difficulty of which</I></DIV><DIV><I>=A0=A0 has not been altered.=A0 =
Security considerations are covered in</I></DIV><DIV><I>=A0=A0 [RFC2328] =
and [RFC2740] for the base OSPF protocol and in =
[RFC1194]</I></DIV><DIV><I>=A0=A0 for IS-IS.=A0 As the LSPs may now =
contain additional information</I></DIV><DIV><I>=A0=A0 regarding router =
capabilities, this new information would also become</I></DIV><DIV><I>=A0 =
=A0available.=A0 Note that intentional or unintentional advertisement =
of</I></DIV><DIV><I>=A0=A0 "fake" TE Mesh Groups by an LSR A does not =
have any impact on other</I></DIV><DIV><I>=A0=A0 LSRs since an LSR B =
would only try to signal a TE LSP torward that</I></DIV><DIV><I>=A0=A0 =
advertizing LSR A to join the advertized TE Mesh TE Group if and =
only</I></DIV><DIV><I>=A0=A0 if such TE Mesh Group is also locally =
configured on LSR B.</I></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>+ new references =
added.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Does that address the =
comments ?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>JP.</DIV></BODY></HTML>=

--Apple-Mail-36-146102614--



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 12:21:12 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 15:20:02 +0200
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: AcbdftFBQ4XXOrHzQmehkQbu8IRfdwAAc4dA
From: "Nurit Sprecher" <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

I approve the liaison as stated.=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Loa Andersson
Sent: Thursday, September 21, 2006 14:03
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Proposed liaison response to IEEE

All,

there have been a number of correct statements in this short thread.

Neil is right (given the layered network model) that Ethernet is a layer
network and as such connectionless and packet oriented.

Nurit is right that if you configure a VLAN on only to parts of an
Ethernet bridge the frame will go through without looking at the MAC
address

Don is right that the liaison does not capture an earlier comment he
made on the gels-list. Neither does it capture a comment made by Attila.

However, if I understand what is happening here is that we need to
clarify a paragraph in the liaison form the IEEE802.1 on translation of
S-VIDs.

I guess that this is something we all need to understand, and given the
answer, it will be possible to follow up with further more precise
questions.

If for example the answer on S-VID translation is that it is not
supported other than at domain borders, then the question on whether it
needs to be done by taking the MAC-address into consideration or not
will have very different meaning.

Let agree on getting the liaison out, and then decide on what we do next
depending on the answer.

/Loa

Nurit Sprecher wrote:
> Hi Neil,
> Thanks for your clarification.=20
> Please note that the discussion below relates to the liaison that the=20
> IETF wants to send to the IEEE in order to understand the standard=20
> behavior of the Ethernet forwarding behavior. As I understand it, Don=20
> was concerned that S-VID translation does not preclude the forwarding=20
> decision which is based on the MAC address. My intention was to=20
> indicate that for point-to-point VLAN connection (on a link), MAC=20
> learning is not required by the 802.1Qrev-5 spec and the forwarding=20
> decision does not rely on the MAC address. This is not a discussion on

> networking but on the standard behavior of the 802.1Q bridges.
> Regards,
> Nuritl.
>=20
> ________________________________
>=20
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, September 21, 2006 13:00
> To: Nurit Sprecher; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Proposed liaison response to IEEE
>=20
>=20
> Nurit.....precision is indeed important.  In a co mode layer network=20
> connections can be p2p or p2mp in nature and each can be composed of=20
> multiple concatenated subnetwork-connections (ie nodes in THIS layer
> network) and link-connections......noting that a single p2p=20
> link-connection hop between 2 bridges in a cl-ps Ethernet layer=20
> network is NOT a connection in THAT (ie Ethernet) layer network=20
> (though it will be supported by a trail which is provided by a=20
> connection in some lower layer network).
> =20
> regards, Neil
>=20
> 	-----Original Message-----
> 	From: [e-mail] [mailto:[e-mail]]
On=20
> Behalf Of Nurit Sprecher
> 	Sent: 21 September 2006 12:38
> 	To: Don Fedyk; Adrian Farrel
> 	Cc: [e-mail]; Wijnen, Bert (Bert); [e-mail];
Nurit=20
> Sprecher
> 	Subject: RE: Proposed liaison response to IEEE
> =09
> =09
>=20
> 	Hi,
>=20
> 	=20
>=20
> 	I think it is a good idea to send the liaison to the IEEE and
get=20
> once and for all a clear statement that the s-vid translation is=20
> supported on each provider bridge port.
>=20
> 	=20
>=20
> 	In addition, the IEEE has recognized that MAC learning is not=20
> required for point-to-point VLANs in a bridge. The 802.1Q rev-5=20
> already includes this extension in section 8.7.
>=20
> 	=20
>=20
> 	" The Learning Process receives the source MAC Addresses and
VIDs of=20
> received frames from the
>=20
> 	Forwarding Process, following the application of the ingress
rules=20
> (8.6.2). It shall create or update a
>=20
> 	Dynamic Filtering Entry (8.8.3) that specifies the reception
Port for=20
> the frame's source address and VID, if
>=20
> 	and only if the source address is an Individual Address, i.e.,
is not=20
> a Group Address, the resulting number of
>=20
> 	entries would not exceed the capacity of the Filtering Database,
and=20
> the filtering utility criteria for the
>=20
> 	receiving Bridge Port are met."
>=20
> 	The enhanced filtering utility criteria "are satisfied if at
least=20
> one VLAN that uses the FID includes the reception Port and at least=20
> one other Port with a Port State of Learning or Forwarding in its=20
> member set, and: a) The operPointToPointMAC parameter is false for the

> reception Port; or b) Ingress to the VLAN is permitted through a third

> Port. NOTE -The third port can, but is not required to be in the=20
> member set.".
>=20
> 	=20
>=20
> 	I think it is clearly stated, but if it is required to ask the
IEEE=20
> about the context of forwarding based on a destination MAC, I suggest=20
> being more precise and specify that we are talking on point-to-point=20
> connections.
>=20
> 	=20
>=20
> 	Regards,
>=20
> 	Nurit.
>=20
> 	=20
>=20
> 	-----Original Message-----
> 	From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Don Fedyk
> 	Sent: Wednesday, September 20, 2006 23:16
> 	To: Adrian Farrel; [e-mail]
> 	Cc: [e-mail]; Wijnen, Bert (Bert)
> 	Subject: RE: Proposed liaison response to IEEE
>=20
> 	=20
>=20
> 	Hi Adrian
>=20
> 	=20
>=20
> 	The Liaison looks good however it does not capture a comment I
> made.  =20
>=20
> 	=20
>=20
> 	My understanding of the S-VLAN translation in IEEE documents and
the
>=20
> 	liaison is that the translation is valid in the context of
forwarding
>=20
> 	based on a destination MAC. My interpretation is that V-LAN is=20
> optional
>=20
> 	MAC is not. If I am correct VLAN translation as specified is not

> equal
>=20
> 	to Label switching. The Liaison is clear about not just the
format of
>=20
> 	'packets on the wire' but the relationship to the entities such
as=20
> MAC
>=20
> 	relay as well. =20
>=20
> 	=20
>=20
> 	I think we should also ask in our liaison for clarification if
the
>=20
> 	S-VLAN translation can be valid by itself i.e. as a label
agnostic to
>=20
> 	the MAC so there is no confusion.
>=20
> 	=20
>=20
> 	Thanks,
>=20
> 	Don
>=20
> 	=20
>=20
> 	=20
>=20
> 	> -----Original Message-----
>=20
> 	> From: [e-mail]
>=20
> 	> All,
>=20
> 	>
>=20
> 	> The IETF received an unsolicited liaison on the subject of
>=20
> 	> 802.1 Ethernet
>=20
> 	>
>=20
> 	> You can see the liaison at
>=20
> 	> https://datatracker.ietf.org/documents/LIAISON/file358.pdf
>=20
> 	>
>=20
> 	> The participants on the GELS mailing list have requested that
>=20
> 	> we respond to this to clarify an issue.
>=20
> 	>
>=20
> 	> Here is the draft of a liaison that we proposed to send.=20
>=20
> 	> Please shout at once if you have any concerns with this
>=20
> 	> liaison. I intend to ask Bert to send it on Monday of next
week.
>=20
> 	>
>=20
> 	> Thanks,
>=20
> 	> Adrian
>=20
> 	> =3D=3D=3D
>=20
> 	> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN
tags"
>=20
> 	>
>=20
> 	> Date: Sep 2006
>=20
> 	> To: IEEE802.1
>=20
> 	>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]
>=20
> 	>
>=20
> 	> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
>=20
> 	>           Adrian Farrel, IETF CCAMP Working Group co-chair
>=20
> 	>           Deborah Brungard, IETF CCAMP Working Group co-chair
>=20
> 	>
>=20
> 	> Cc: Bernard Aboba [e-mail]
>=20
> 	>        Ross Callon [e-mail]
>=20
> 	>        Bill Fenner [e-mail]
>=20
> 	>        CCAMP mailing list [e-mail]
>=20
> 	>        GELS mailing list  [e-mail]
>=20
> 	>
>=20
> 	> Thank you for your very informative and clarifying liaison on
>=20
> 	> "Use of IEEE 802.1Q VLAN tags".
>=20
> 	>
>=20
> 	> We have a question arising from this liaison and our reading
>=20
> 	> of the relevant standards documents as follows.
>=20
> 	>
>=20
> 	> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12
>=20
> 	> bit VIDs) is supported at S-tagged service interfaces, as an
>=20
> 	> option, by the IEEE Std 802.1ad Provider Bridging amendment
>=20
> 	> to IEEE Std 802.1Q."
>=20
> 	>
>=20
> 	> While this text in itself is clear it leaves open the
>=20
> 	> question of whether "S-tagged Service interfaces" is the only
>=20
> 	> type of interface where Translation of 802.1Q S-VLAN tags is
>=20
> 	> supported.
>=20
> 	>
>=20
> 	> It is our understanding that IEEE Std 802.1ad does not
>=20
> 	> preclude the translation of 802.1Q S-VLAN tags at any
>=20
> 	> S-tagged interface. Thus, this translation would be allowed
>=20
> 	> at Provider Network Ports, not just at Customer Network Ports.
>=20
> 	>
>=20
> 	> Can you please confirm whether this is the correct
>=20
> 	> interpretation of the IEEE Std 802.1ad amendment to the IEEE
>=20
> 	> Std 802.1Q?
>=20
> 	>
>=20
> 	> Many thanks,
>=20
> 	>
>=20
> 	> Bert Wijnen, IETF liaison to IEEE 802.1
>=20
> 	> Adrian Farrel and Deborah Brungard, CCAMP Working Group
co-chairs
>=20
> 	>
>=20
> 	>
>=20
> 	>
>=20
> 	>
>=20
> 	=20
>=20
> 	_______________________________________________
>=20
> 	gels mailing list
>=20
> 	[e-mail]
>=20
> 	https://rtg.ietf.org/mailman/listinfo/gels
>=20
> 	=20
>=20
>=20


--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                           [e-mail]
_______________________________________________
gels mailing list
[e-mail]
https://rtg.ietf.org/mailman/listinfo/gels





Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 12:03:54 +0000
Message-ID: <[e-mail]>
Date: Thu, 21 Sep 2006 14:02:55 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
CC:  [e-mail],  [e-mail],  [e-mail]
Subject: Re: Proposed liaison response to IEEE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

there have been a number of correct statements in this short
thread.

Neil is right (given the layered network model) that Ethernet
is a layer network and as such connectionless and packet oriented.

Nurit is right that if you configure a VLAN on only to parts of an
Ethernet bridge the frame will go through without looking at the
MAC address

Don is right that the liaison does not capture an earlier comment
he made on the gels-list. Neither does it capture a comment made
by Attila.

However, if I understand what is happening here is that we need
to clarify a paragraph in the liaison form the IEEE802.1 on
translation of S-VIDs.

I guess that this is something we all need to understand, and
given the answer, it will be possible to follow up with further
more precise questions.

If for example the answer on S-VID translation is that it is not
supported other than at domain borders, then the question on whether
it needs to be done by taking the MAC-address into consideration
or not will have very different meaning.

Let agree on getting the liaison out, and then decide on what we
do next depending on the answer.

/Loa

Nurit Sprecher wrote:
> Hi Neil,
> Thanks for your clarification. 
> Please note that the discussion below relates to the liaison that the
> IETF wants to send to the IEEE in order to understand the standard
> behavior of the Ethernet forwarding behavior. As I understand it, Don
> was concerned that S-VID translation does not preclude the forwarding
> decision which is based on the MAC address. My intention was to indicate
> that for point-to-point VLAN connection (on a link), MAC learning is not
> required by the 802.1Qrev-5 spec and the forwarding decision does not
> rely on the MAC address. This is not a discussion on networking but on
> the standard behavior of the 802.1Q bridges.
> Regards,
> Nuritl.
> 
> ________________________________
> 
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, September 21, 2006 13:00
> To: Nurit Sprecher; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Proposed liaison response to IEEE
> 
> 
> Nurit.....precision is indeed important.  In a co mode layer network
> connections can be p2p or p2mp in nature and each can be composed of
> multiple concatenated subnetwork-connections (ie nodes in THIS layer
> network) and link-connections......noting that a single p2p
> link-connection hop between 2 bridges in a cl-ps Ethernet layer network
> is NOT a connection in THAT (ie Ethernet) layer network (though it will
> be supported by a trail which is provided by a connection in some lower
> layer network).
>  
> regards, Neil
> 
> 	-----Original Message-----
> 	From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Nurit Sprecher
> 	Sent: 21 September 2006 12:38
> 	To: Don Fedyk; Adrian Farrel
> 	Cc: [e-mail]; Wijnen, Bert (Bert); [e-mail];
> Nurit Sprecher
> 	Subject: RE: Proposed liaison response to IEEE
> 	
> 	
> 
> 	Hi,
> 
> 	 
> 
> 	I think it is a good idea to send the liaison to the IEEE and
> get once and for all a clear statement that the s-vid translation is
> supported on each provider bridge port. 
> 
> 	 
> 
> 	In addition, the IEEE has recognized that MAC learning is not
> required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already
> includes this extension in section 8.7. 
> 
> 	 
> 
> 	" The Learning Process receives the source MAC Addresses and
> VIDs of received frames from the
> 
> 	Forwarding Process, following the application of the ingress
> rules (8.6.2). It shall create or update a
> 
> 	Dynamic Filtering Entry (8.8.3) that specifies the reception
> Port for the frame's source address and VID, if
> 
> 	and only if the source address is an Individual Address, i.e.,
> is not a Group Address, the resulting number of
> 
> 	entries would not exceed the capacity of the Filtering Database,
> and the filtering utility criteria for the
> 
> 	receiving Bridge Port are met."
> 
> 	The enhanced filtering utility criteria "are satisfied if at
> least one VLAN that uses the FID includes the reception Port and at
> least one other Port with a Port State of Learning or Forwarding in its
> member set, and: a) The operPointToPointMAC parameter is false for the
> reception Port; or b) Ingress to the VLAN is permitted through a third
> Port. NOTE -The third port can, but is not required to be in the member
> set.". 
> 
> 	 
> 
> 	I think it is clearly stated, but if it is required to ask the
> IEEE about the context of forwarding based on a destination MAC, I
> suggest being more precise and specify that we are talking on
> point-to-point connections.
> 
> 	 
> 
> 	Regards,
> 
> 	Nurit.
> 
> 	 
> 
> 	-----Original Message-----
> 	From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Don Fedyk
> 	Sent: Wednesday, September 20, 2006 23:16
> 	To: Adrian Farrel; [e-mail]
> 	Cc: [e-mail]; Wijnen, Bert (Bert)
> 	Subject: RE: Proposed liaison response to IEEE
> 
> 	 
> 
> 	Hi Adrian
> 
> 	 
> 
> 	The Liaison looks good however it does not capture a comment I
> made.   
> 
> 	 
> 
> 	My understanding of the S-VLAN translation in IEEE documents and
> the
> 
> 	liaison is that the translation is valid in the context of
> forwarding
> 
> 	based on a destination MAC. My interpretation is that V-LAN is
> optional
> 
> 	MAC is not. If I am correct VLAN translation as specified is not
> equal
> 
> 	to Label switching. The Liaison is clear about not just the
> format of
> 
> 	'packets on the wire' but the relationship to the entities such
> as MAC
> 
> 	relay as well.  
> 
> 	 
> 
> 	I think we should also ask in our liaison for clarification if
> the
> 
> 	S-VLAN translation can be valid by itself i.e. as a label
> agnostic to
> 
> 	the MAC so there is no confusion.
> 
> 	 
> 
> 	Thanks,
> 
> 	Don
> 
> 	 
> 
> 	 
> 
> 	> -----Original Message-----
> 
> 	> From: [e-mail] 
> 
> 	> All,
> 
> 	> 
> 
> 	> The IETF received an unsolicited liaison on the subject of 
> 
> 	> 802.1 Ethernet
> 
> 	> 
> 
> 	> You can see the liaison at
> 
> 	> https://datatracker.ietf.org/documents/LIAISON/file358.pdf
> 
> 	> 
> 
> 	> The participants on the GELS mailing list have requested that 
> 
> 	> we respond to this to clarify an issue.
> 
> 	> 
> 
> 	> Here is the draft of a liaison that we proposed to send. 
> 
> 	> Please shout at once if you have any concerns with this 
> 
> 	> liaison. I intend to ask Bert to send it on Monday of next
> week.
> 
> 	> 
> 
> 	> Thanks,
> 
> 	> Adrian
> 
> 	> ===
> 
> 	> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN
> tags"
> 
> 	> 
> 
> 	> Date: Sep 2006
> 
> 	> To: IEEE802.1
> 
> 	>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]
> 
> 	> 
> 
> 	> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
> 
> 	>           Adrian Farrel, IETF CCAMP Working Group co-chair
> 
> 	>           Deborah Brungard, IETF CCAMP Working Group co-chair
> 
> 	> 
> 
> 	> Cc: Bernard Aboba [e-mail]
> 
> 	>        Ross Callon [e-mail]
> 
> 	>        Bill Fenner [e-mail]
> 
> 	>        CCAMP mailing list [e-mail]
> 
> 	>        GELS mailing list  [e-mail]
> 
> 	> 
> 
> 	> Thank you for your very informative and clarifying liaison on 
> 
> 	> "Use of IEEE 802.1Q VLAN tags".
> 
> 	> 
> 
> 	> We have a question arising from this liaison and our reading 
> 
> 	> of the relevant standards documents as follows.
> 
> 	> 
> 
> 	> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 
> 
> 	> bit VIDs) is supported at S-tagged service interfaces, as an 
> 
> 	> option, by the IEEE Std 802.1ad Provider Bridging amendment 
> 
> 	> to IEEE Std 802.1Q."
> 
> 	> 
> 
> 	> While this text in itself is clear it leaves open the 
> 
> 	> question of whether "S-tagged Service interfaces" is the only 
> 
> 	> type of interface where Translation of 802.1Q S-VLAN tags is 
> 
> 	> supported.
> 
> 	> 
> 
> 	> It is our understanding that IEEE Std 802.1ad does not 
> 
> 	> preclude the translation of 802.1Q S-VLAN tags at any 
> 
> 	> S-tagged interface. Thus, this translation would be allowed 
> 
> 	> at Provider Network Ports, not just at Customer Network Ports.
> 
> 	> 
> 
> 	> Can you please confirm whether this is the correct 
> 
> 	> interpretation of the IEEE Std 802.1ad amendment to the IEEE 
> 
> 	> Std 802.1Q?
> 
> 	> 
> 
> 	> Many thanks,
> 
> 	> 
> 
> 	> Bert Wijnen, IETF liaison to IEEE 802.1
> 
> 	> Adrian Farrel and Deborah Brungard, CCAMP Working Group
> co-chairs
> 
> 	> 
> 
> 	> 
> 
> 	> 
> 
> 	> 
> 
> 	 
> 
> 	_______________________________________________
> 
> 	gels mailing list
> 
> 	[e-mail]
> 
> 	https://rtg.ietf.org/mailman/listinfo/gels
> 
> 	 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                           [e-mail]



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 11:16:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD77.8E066949"
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 14:14:57 +0200
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gAABJOyw
From: "Nurit Sprecher" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Nurit Sprecher" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DD77.8E066949
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Neil,
Thanks for your clarification.=20
Please note that the discussion below relates to the liaison that the
IETF wants to send to the IEEE in order to understand the standard
behavior of the Ethernet forwarding behavior. As I understand it, Don
was concerned that S-VID translation does not preclude the forwarding
decision which is based on the MAC address. My intention was to indicate
that for point-to-point VLAN connection (on a link), MAC learning is not
required by the 802.1Qrev-5 spec and the forwarding decision does not
rely on the MAC address. This is not a discussion on networking but on
the standard behavior of the 802.1Q bridges.
Regards,
Nuritl.

________________________________

From: [e-mail] [mailto:[e-mail]]=20
Sent: Thursday, September 21, 2006 13:00
To: Nurit Sprecher; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Proposed liaison response to IEEE


Nurit.....precision is indeed important.  In a co mode layer network
connections can be p2p or p2mp in nature and each can be composed of
multiple concatenated subnetwork-connections (ie nodes in THIS layer
network) and link-connections......noting that a single p2p
link-connection hop between 2 bridges in a cl-ps Ethernet layer network
is NOT a connection in THAT (ie Ethernet) layer network (though it will
be supported by a trail which is provided by a connection in some lower
layer network).
=20
regards, Neil

	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]]
On Behalf Of Nurit Sprecher
	Sent: 21 September 2006 12:38
	To: Don Fedyk; Adrian Farrel
	Cc: [e-mail]; Wijnen, Bert (Bert); [e-mail];
Nurit Sprecher
	Subject: RE: Proposed liaison response to IEEE
=09
=09

	Hi,

	=20

	I think it is a good idea to send the liaison to the IEEE and
get once and for all a clear statement that the s-vid translation is
supported on each provider bridge port.=20

	=20

	In addition, the IEEE has recognized that MAC learning is not
required for point-to-point VLANs in a bridge. The 802.1Q rev-5 already
includes this extension in section 8.7.=20

	=20

	" The Learning Process receives the source MAC Addresses and
VIDs of received frames from the

	Forwarding Process, following the application of the ingress
rules (8.6.2). It shall create or update a

	Dynamic Filtering Entry (8.8.3) that specifies the reception
Port for the frame's source address and VID, if

	and only if the source address is an Individual Address, i.e.,
is not a Group Address, the resulting number of

	entries would not exceed the capacity of the Filtering Database,
and the filtering utility criteria for the

	receiving Bridge Port are met."

	The enhanced filtering utility criteria "are satisfied if at
least one VLAN that uses the FID includes the reception Port and at
least one other Port with a Port State of Learning or Forwarding in its
member set, and: a) The operPointToPointMAC parameter is false for the
reception Port; or b) Ingress to the VLAN is permitted through a third
Port. NOTE -The third port can, but is not required to be in the member
set.".=20

	=20

	I think it is clearly stated, but if it is required to ask the
IEEE about the context of forwarding based on a destination MAC, I
suggest being more precise and specify that we are talking on
point-to-point connections.

	=20

	Regards,

	Nurit.

	=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Don Fedyk
	Sent: Wednesday, September 20, 2006 23:16
	To: Adrian Farrel; [e-mail]
	Cc: [e-mail]; Wijnen, Bert (Bert)
	Subject: RE: Proposed liaison response to IEEE

	=20

	Hi Adrian

	=20

	The Liaison looks good however it does not capture a comment I
made.  =20

	=20

	My understanding of the S-VLAN translation in IEEE documents and
the

	liaison is that the translation is valid in the context of
forwarding

	based on a destination MAC. My interpretation is that V-LAN is
optional

	MAC is not. If I am correct VLAN translation as specified is not
equal

	to Label switching. The Liaison is clear about not just the
format of

	'packets on the wire' but the relationship to the entities such
as MAC

	relay as well. =20

	=20

	I think we should also ask in our liaison for clarification if
the

	S-VLAN translation can be valid by itself i.e. as a label
agnostic to

	the MAC so there is no confusion.

	=20

	Thanks,

	Don

	=20

	=20

	> -----Original Message-----

	> From: [e-mail]=20

	> All,

	>=20

	> The IETF received an unsolicited liaison on the subject of=20

	> 802.1 Ethernet

	>=20

	> You can see the liaison at

	> https://datatracker.ietf.org/documents/LIAISON/file358.pdf

	>=20

	> The participants on the GELS mailing list have requested that=20

	> we respond to this to clarify an issue.

	>=20

	> Here is the draft of a liaison that we proposed to send.=20

	> Please shout at once if you have any concerns with this=20

	> liaison. I intend to ask Bert to send it on Monday of next
week.

	>=20

	> Thanks,

	> Adrian

	> =3D=3D=3D

	> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN
tags"

	>=20

	> Date: Sep 2006

	> To: IEEE802.1

	>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]

	>=20

	> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1

	>           Adrian Farrel, IETF CCAMP Working Group co-chair

	>           Deborah Brungard, IETF CCAMP Working Group co-chair

	>=20

	> Cc: Bernard Aboba [e-mail]

	>        Ross Callon [e-mail]

	>        Bill Fenner [e-mail]

	>        CCAMP mailing list [e-mail]

	>        GELS mailing list  [e-mail]

	>=20

	> Thank you for your very informative and clarifying liaison on=20

	> "Use of IEEE 802.1Q VLAN tags".

	>=20

	> We have a question arising from this liaison and our reading=20

	> of the relevant standards documents as follows.

	>=20

	> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20

	> bit VIDs) is supported at S-tagged service interfaces, as an=20

	> option, by the IEEE Std 802.1ad Provider Bridging amendment=20

	> to IEEE Std 802.1Q."

	>=20

	> While this text in itself is clear it leaves open the=20

	> question of whether "S-tagged Service interfaces" is the only=20

	> type of interface where Translation of 802.1Q S-VLAN tags is=20

	> supported.

	>=20

	> It is our understanding that IEEE Std 802.1ad does not=20

	> preclude the translation of 802.1Q S-VLAN tags at any=20

	> S-tagged interface. Thus, this translation would be allowed=20

	> at Provider Network Ports, not just at Customer Network Ports.

	>=20

	> Can you please confirm whether this is the correct=20

	> interpretation of the IEEE Std 802.1ad amendment to the IEEE=20

	> Std 802.1Q?

	>=20

	> Many thanks,

	>=20

	> Bert Wijnen, IETF liaison to IEEE 802.1

	> Adrian Farrel and Deborah Brungard, CCAMP Working Group
co-chairs

	>=20

	>=20

	>=20

	>=20

	=20

	_______________________________________________

	gels mailing list

	[e-mail]

	https://rtg.ietf.org/mailman/listinfo/gels

	=20


------_=_NextPart_001_01C6DD77.8E066949
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR><o:SmartTagType =

namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PlaceType"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PlaceName"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"=20
downloadurl=3D"http://www.5iantlavalamp.com/"></o:SmartTagType><!--[if =
!mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 1.0in 69.6pt 1.0in =
69.6pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D476560512-21092006><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Neil,</FONT></SPAN></DIV>
<DIV><SPAN class=3D476560512-21092006><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
for your clarification. </FONT></SPAN></DIV>
<DIV><SPAN class=3D476560512-21092006><FONT face=3DArial color=3D#0000ff =
size=3D2>Please=20
note that the discussion below relates to the liaison that the IETF =
wants to=20
send to the IEEE in order to understand the standard behavior of the =
Ethernet=20
forwarding behavior. As I understand it, Don was concerned that S-VID=20
translation does not preclude the forwarding decision which is based on =
the MAC=20
address. My&nbsp;intention was to indicate that for point-to-point VLAN=20
connection (on a link), MAC learning is not required by the 802.1Qrev-5 =
spec and=20
the forwarding decision does not rely on the MAC address. This is not a=20
discussion on networking but on the standard behavior of the 802.1Q=20
bridges.</FONT></SPAN></DIV>
<DIV><SPAN class=3D476560512-21092006><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D476560512-21092006><FONT face=3DArial color=3D#0000ff =

size=3D2>Nuritl.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <BR><B>Sent:</B> Thursday, September 21, =
2006=20
13:00<BR><B>To:</B> Nurit Sprecher; [e-mail];=20
[e-mail]<BR><B>Cc:</B> [e-mail]; [e-mail]; =

[e-mail]<BR><B>Subject:</B> RE: Proposed liaison response to=20
IEEE<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=3D353154410-21092006><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Nurit.....precision is indeed important.&nbsp; In a co mode =
layer network=20
connections can be p2p or p2mp in nature and each can be composed of =
multiple=20
concatenated subnetwork-connections (ie nodes in THIS layer network) and =

link-connections......noting that a single p2p link-connection hop =
between 2=20
bridges in a cl-ps Ethernet layer network&nbsp;is NOT a connection in =
THAT (ie=20
Ethernet) layer network (though it will be supported by a trail which is =

provided by a connection in some lower layer =
network).</FONT></SPAN></DIV>
<DIV><SPAN class=3D353154410-21092006><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D353154410-21092006><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>Nurit Sprecher<BR><B>Sent:</B> 21 September 2006 =
12:38<BR><B>To:</B> Don=20
  Fedyk; Adrian Farrel<BR><B>Cc:</B> [e-mail]; Wijnen, Bert =
(Bert);=20
  [e-mail]; Nurit Sprecher<BR><B>Subject:</B> RE: Proposed =
liaison=20
  response to IEEE<BR><BR></FONT></DIV>
  <DIV class=3DSection1 dir=3Drtl>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I think it is a good idea to send the =
liaison to the=20
  IEEE and get once and for all a clear statement that the s-vid =
translation is=20
  supported on each provider bridge port. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">In addition, the IEEE has recognized that =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">MAC learning is not required for =
point-to-point=20
  VLANs in a bridge</SPAN></B>. <B><SPAN style=3D"FONT-WEIGHT: bold">The =
802.1Q=20
  rev-5 already includes this extension in section 8.7</SPAN></B>.=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">" The Learning Process receives the source =
MAC=20
  Addresses and VIDs of received frames from =
the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Forwarding Process, following the =
application of the=20
  ingress rules (8.6.2). <B><SPAN style=3D"FONT-WEIGHT: bold">It shall =
create or=20
  update a<o:p></o:p></SPAN></B></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">Dynamic Filtering Entry =
(8.8.3)=20
  that specifies the <st1:place w:st=3D"on"><st1:PlaceName=20
  w:st=3D"on">reception</st1:PlaceName> <st1:PlaceType=20
  w:st=3D"on">Port</st1:PlaceType></st1:place> for the frame&#8217;s =
source address and=20
  VID, if<o:p></o:p></SPAN></FONT></B></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">and only if =
</SPAN></FONT></B>the=20
  source address is an Individual Address, i.e., is not a Group Address, =
the=20
  resulting number of<o:p></o:p></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">entries would not exceed the capacity of the =
Filtering=20
  Database, <B><SPAN style=3D"FONT-WEIGHT: bold">and the filtering =
utility=20
  criteria for the<o:p></o:p></SPAN></B></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">receiving <st1:place=20
  w:st=3D"on"><st1:PlaceType w:st=3D"on">Bridge</st1:PlaceType> =
<st1:PlaceType=20
  w:st=3D"on">Port</st1:PlaceType></st1:place> are =
met."</SPAN></FONT></B><B><SPAN=20
  lang=3DHE dir=3Drtl style=3D"FONT-WEIGHT: =
bold"><o:p></o:p></SPAN></B></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">The enhanced filtering utility criteria "are =
satisfied=20
  if at least one VLAN that uses the FID includes the reception Port and =
at=20
  least one other Port with a Port State of Learning or Forwarding in =
its member=20
  set, and: a) The operPointToPointMAC parameter is false for the =
reception=20
  Port; or b) Ingress to the VLAN is permitted through a third Port. =
NOTE &#8212;The=20
  third port can, but is not required to be in the member set.".=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I think it is clearly stated, but if it is =
required to=20
  ask the IEEE about the context of forwarding based on a destination =
MAC,=20
  <B><SPAN style=3D"FONT-WEIGHT: bold">I suggest being more precise and =
specify=20
  that we are talking on</SPAN></B> <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">point-to-point=20
  connections.<o:p></o:p></SPAN></B></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></B></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Regards,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Nurit.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">-----Original Message-----<BR>From:=20
  [e-mail] [mailto:[e-mail]] On Behalf =
Of Don=20
  Fedyk<BR>Sent: Wednesday, September 20, 2006 23:16<BR>To: Adrian =
Farrel;=20
  [e-mail]<BR>Cc: [e-mail]; Wijnen, Bert =
(Bert)<BR>Subject:=20
  RE: Proposed liaison response to IEEE</SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Hi Adrian<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">The Liaison looks good however it does not =
capture a=20
  comment I made.&nbsp;&nbsp; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">My understanding of the S-VLAN translation =
in IEEE=20
  documents and the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">liaison is that the translation is valid in =
the=20
  context of forwarding<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">based on a destination MAC. My =
interpretation is that=20
  V-LAN is optional<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">MAC is not. If I am correct VLAN translation =
as=20
  specified is not equal<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">to Label switching. The Liaison is clear =
about not=20
  just the format of<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">'packets on the wire' but the relationship =
to the=20
  entities such as MAC<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">relay as well.&nbsp; =
<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I think we should also ask in our liaison =
for=20
  clarification if the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">S-VLAN translation can be valid by itself =
i.e. as a=20
  label agnostic to<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">the MAC so there is no=20
  confusion.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Don<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; -----Original=20
  Message-----<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; From: [e-mail]=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; All,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; The IETF received an unsolicited =
liaison on the=20
  subject of <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; 802.1 =
Ethernet<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; You can see the liaison=20
  at<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt;=20
  =
https://datatracker.ietf.org/documents/LIAISON/file358.pdf<o:p></o:p></SP=
AN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; The participants on the GELS mailing =
list have=20
  requested that <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; we respond to this to clarify an=20
  issue.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Here is the draft of a liaison that we =
proposed=20
  to send. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Please shout at once if you have any =
concerns=20
  with this <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; liaison. I intend to ask Bert to send =
it on=20
  Monday of next week.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <st1:City w:st=3D"on"><st1:place=20
  w:st=3D"on">Adrian</st1:place></st1:City><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; =3D=3D=3D<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Subject: Response to your liaison "Use =
of IEEE=20
  802.1Q VLAN tags"<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Date: Sep =
2006<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; To: =
IEEE802.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tony =
Jeffree, IEEE=20
  802.1 WG Chair, [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; From: Bert Wijnen, IETF liaison to IETF =
liaison=20
  to IEEE 802.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Adrian Farrel, IETF CCAMP Working Group =
co-chair<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Deborah Brungard, IETF CCAMP Working Group=20
  co-chair<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Cc: Bernard Aboba=20
  [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ross=20
  Callon [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bill=20
  Fenner [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CCAMP=20
  mailing list [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GELS=20
  mailing list&nbsp; [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Thank you for your very informative and =

  clarifying liaison on <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; "Use of IEEE 802.1Q VLAN=20
  tags".<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; We have a question arising from this =
liaison and=20
  our reading <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; of the relevant standards documents as=20
  follows.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; The liaison says: "Translation of =
802.1Q S-VLAN=20
  tags (with 12 <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; bit VIDs) is supported at S-tagged =
service=20
  interfaces, as an <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; option, by the IEEE Std 802.1ad =
Provider Bridging=20
  amendment <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; to IEEE Std =
802.1Q."<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; While this text in itself is clear it =
leaves open=20
  the <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; question of whether "S-tagged Service =
interfaces"=20
  is the only <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; type of interface where Translation of =
802.1Q=20
  S-VLAN tags is <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; supported.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; It is our understanding that IEEE Std =
802.1ad=20
  does not <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; preclude the translation of 802.1Q =
S-VLAN tags at=20
  any <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; S-tagged interface. Thus, this =
translation would=20
  be allowed <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; at Provider Network Ports, not just at =
Customer=20
  Network Ports.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Can you please confirm whether this is =
the=20
  correct <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; interpretation of the IEEE Std 802.1ad =
amendment=20
  to the IEEE <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Std =
802.1Q?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Many =
thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Bert Wijnen, IETF liaison to IEEE=20
  802.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Adrian Farrel and Deborah Brungard, =
CCAMP Working=20
  Group co-chairs<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">_______________________________________________<o:p></o:p></SPAN></=
FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">gels mailing =
list<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">[e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">https://rtg.ietf.org/mailman/listinfo/gels<o:p></o:p></SPAN></FONT>=
</P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C6DD77.8E066949--



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 11:00:34 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD6D.1821739E"
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 12:00:05 +0100
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gA==
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DD6D.1821739E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Nurit.....precision is indeed important.  In a co mode layer network
connections can be p2p or p2mp in nature and each can be composed of
multiple concatenated subnetwork-connections (ie nodes in THIS layer
network) and link-connections......noting that a single p2p
link-connection hop between 2 bridges in a cl-ps Ethernet layer network
is NOT a connection in THAT (ie Ethernet) layer network (though it will
be supported by a trail which is provided by a connection in some lower
layer network).
=20
regards, Neil

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Nurit Sprecher
Sent: 21 September 2006 12:38
To: Don Fedyk; Adrian Farrel
Cc: [e-mail]; Wijnen, Bert (Bert); [e-mail]; Nurit
Sprecher
Subject: RE: Proposed liaison response to IEEE



Hi,

=20

I think it is a good idea to send the liaison to the IEEE and get once
and for all a clear statement that the s-vid translation is supported on
each provider bridge port.=20

=20

In addition, the IEEE has recognized that MAC learning is not required
for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes
this extension in section 8.7.=20

=20

" The Learning Process receives the source MAC Addresses and VIDs of
received frames from the

Forwarding Process, following the application of the ingress rules
(8.6.2). It shall create or update a

Dynamic Filtering Entry (8.8.3) that specifies the reception Port for
the frame's source address and VID, if

and only if the source address is an Individual Address, i.e., is not a
Group Address, the resulting number of

entries would not exceed the capacity of the Filtering Database, and the
filtering utility criteria for the

receiving Bridge Port are met."

The enhanced filtering utility criteria "are satisfied if at least one
VLAN that uses the FID includes the reception Port and at least one
other Port with a Port State of Learning or Forwarding in its member
set, and: a) The operPointToPointMAC parameter is false for the
reception Port; or b) Ingress to the VLAN is permitted through a third
Port. NOTE -The third port can, but is not required to be in the member
set.".=20

=20

I think it is clearly stated, but if it is required to ask the IEEE
about the context of forwarding based on a destination MAC, I suggest
being more precise and specify that we are talking on point-to-point
connections.

=20

Regards,

Nurit.

=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Don Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian Farrel; [e-mail]
Cc: [e-mail]; Wijnen, Bert (Bert)
Subject: RE: Proposed liaison response to IEEE

=20

Hi Adrian

=20

The Liaison looks good however it does not capture a comment I made.  =20

=20

My understanding of the S-VLAN translation in IEEE documents and the

liaison is that the translation is valid in the context of forwarding

based on a destination MAC. My interpretation is that V-LAN is optional

MAC is not. If I am correct VLAN translation as specified is not equal

to Label switching. The Liaison is clear about not just the format of

'packets on the wire' but the relationship to the entities such as MAC

relay as well. =20

=20

I think we should also ask in our liaison for clarification if the

S-VLAN translation can be valid by itself i.e. as a label agnostic to

the MAC so there is no confusion.

=20

Thanks,

Don

=20

=20

> -----Original Message-----

> From: [e-mail]=20

> All,

>=20

> The IETF received an unsolicited liaison on the subject of=20

> 802.1 Ethernet

>=20

> You can see the liaison at

> https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>=20

> The participants on the GELS mailing list have requested that=20

> we respond to this to clarify an issue.

>=20

> Here is the draft of a liaison that we proposed to send.=20

> Please shout at once if you have any concerns with this=20

> liaison. I intend to ask Bert to send it on Monday of next week.

>=20

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags"

>=20

> Date: Sep 2006

> To: IEEE802.1

>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]

>=20

> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1

>           Adrian Farrel, IETF CCAMP Working Group co-chair

>           Deborah Brungard, IETF CCAMP Working Group co-chair

>=20

> Cc: Bernard Aboba [e-mail]

>        Ross Callon [e-mail]

>        Bill Fenner [e-mail]

>        CCAMP mailing list [e-mail]

>        GELS mailing list  [e-mail]

>=20

> Thank you for your very informative and clarifying liaison on=20

> "Use of IEEE 802.1Q VLAN tags".

>=20

> We have a question arising from this liaison and our reading=20

> of the relevant standards documents as follows.

>=20

> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20

> bit VIDs) is supported at S-tagged service interfaces, as an=20

> option, by the IEEE Std 802.1ad Provider Bridging amendment=20

> to IEEE Std 802.1Q."

>=20

> While this text in itself is clear it leaves open the=20

> question of whether "S-tagged Service interfaces" is the only=20

> type of interface where Translation of 802.1Q S-VLAN tags is=20

> supported.

>=20

> It is our understanding that IEEE Std 802.1ad does not=20

> preclude the translation of 802.1Q S-VLAN tags at any=20

> S-tagged interface. Thus, this translation would be allowed=20

> at Provider Network Ports, not just at Customer Network Ports.

>=20

> Can you please confirm whether this is the correct=20

> interpretation of the IEEE Std 802.1ad amendment to the IEEE=20

> Std 802.1Q?

>=20

> Many thanks,

>=20

> Bert Wijnen, IETF liaison to IEEE 802.1

> Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs

>=20

>=20

>=20

>=20

=20

_______________________________________________

gels mailing list

[e-mail]

https://rtg.ietf.org/mailman/listinfo/gels

=20


------_=_NextPart_001_01C6DD6D.1821739E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR><o:SmartTagType =

name=3D"PlaceType"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"PlaceName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"City" =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
name=3D"place" =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
downloadurl=3D"http://www.5iantlavalamp.com/"></o:SmartTagType><!--[if =
!mso]>
<STYLE>
st1\:*{behavior:url(#default#ieooui) }
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 69.6pt 1.0in 69.6pt;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D353154410-21092006><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Nurit.....precision is indeed important.&nbsp; In a co mode =
layer network=20
connections can be p2p or p2mp in nature and each can be composed of =
multiple=20
concatenated subnetwork-connections (ie nodes in THIS layer network) and =

link-connections......noting that a single p2p link-connection hop =
between 2=20
bridges in a cl-ps Ethernet layer network&nbsp;is NOT a connection in =
THAT (ie=20
Ethernet) layer network (though it will be supported by a trail which is =

provided by a connection in some lower layer =
network).</FONT></SPAN></DIV>
<DIV><SPAN class=3D353154410-21092006><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D353154410-21092006><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>Nurit Sprecher<BR><B>Sent:</B> 21 September 2006 =
12:38<BR><B>To:</B> Don=20
  Fedyk; Adrian Farrel<BR><B>Cc:</B> [e-mail]; Wijnen, Bert =
(Bert);=20
  [e-mail]; Nurit Sprecher<BR><B>Subject:</B> RE: Proposed =
liaison=20
  response to IEEE<BR><BR></FONT></DIV>
  <DIV class=3DSection1 dir=3Drtl>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I think it is a good idea to send the =
liaison to the=20
  IEEE and get once and for all a clear statement that the s-vid =
translation is=20
  supported on each provider bridge port. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">In addition, the IEEE has recognized that =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">MAC learning is not required for =
point-to-point=20
  VLANs in a bridge</SPAN></B>. <B><SPAN style=3D"FONT-WEIGHT: bold">The =
802.1Q=20
  rev-5 already includes this extension in section 8.7</SPAN></B>.=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">" The Learning Process receives the source =
MAC=20
  Addresses and VIDs of received frames from =
the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Forwarding Process, following the =
application of the=20
  ingress rules (8.6.2). <B><SPAN style=3D"FONT-WEIGHT: bold">It shall =
create or=20
  update a<o:p></o:p></SPAN></B></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">Dynamic Filtering Entry =
(8.8.3)=20
  that specifies the <st1:place w:st=3D"on"><st1:PlaceName=20
  w:st=3D"on">reception</st1:PlaceName> <st1:PlaceType=20
  w:st=3D"on">Port</st1:PlaceType></st1:place> for the frame&#8217;s =
source address and=20
  VID, if<o:p></o:p></SPAN></FONT></B></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">and only if =
</SPAN></FONT></B>the=20
  source address is an Individual Address, i.e., is not a Group Address, =
the=20
  resulting number of<o:p></o:p></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">entries would not exceed the capacity of the =
Filtering=20
  Database, <B><SPAN style=3D"FONT-WEIGHT: bold">and the filtering =
utility=20
  criteria for the<o:p></o:p></SPAN></B></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt">receiving <st1:place=20
  w:st=3D"on"><st1:PlaceType w:st=3D"on">Bridge</st1:PlaceType> =
<st1:PlaceType=20
  w:st=3D"on">Port</st1:PlaceType></st1:place> are =
met."</SPAN></FONT></B><B><SPAN=20
  lang=3DHE dir=3Drtl style=3D"FONT-WEIGHT: =
bold"><o:p></o:p></SPAN></B></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">The enhanced filtering utility criteria "are =
satisfied=20
  if at least one VLAN that uses the FID includes the reception Port and =
at=20
  least one other Port with a Port State of Learning or Forwarding in =
its member=20
  set, and: a) The operPointToPointMAC parameter is false for the =
reception=20
  Port; or b) Ingress to the VLAN is permitted through a third Port. =
NOTE &#8212;The=20
  third port can, but is not required to be in the member set.".=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I think it is clearly stated, but if it is =
required to=20
  ask the IEEE about the context of forwarding based on a destination =
MAC,=20
  <B><SPAN style=3D"FONT-WEIGHT: bold">I suggest being more precise and =
specify=20
  that we are talking on</SPAN></B> <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">point-to-point=20
  connections.<o:p></o:p></SPAN></B></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><B><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></B></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Regards,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Nurit.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">-----Original Message-----<BR>From:=20
  [e-mail] [mailto:[e-mail]] On Behalf =
Of Don=20
  Fedyk<BR>Sent: Wednesday, September 20, 2006 23:16<BR>To: Adrian =
Farrel;=20
  [e-mail]<BR>Cc: [e-mail]; Wijnen, Bert =
(Bert)<BR>Subject:=20
  RE: Proposed liaison response to IEEE</SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Hi Adrian<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">The Liaison looks good however it does not =
capture a=20
  comment I made.&nbsp;&nbsp; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">My understanding of the S-VLAN translation =
in IEEE=20
  documents and the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">liaison is that the translation is valid in =
the=20
  context of forwarding<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">based on a destination MAC. My =
interpretation is that=20
  V-LAN is optional<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">MAC is not. If I am correct VLAN translation =
as=20
  specified is not equal<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">to Label switching. The Liaison is clear =
about not=20
  just the format of<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">'packets on the wire' but the relationship =
to the=20
  entities such as MAC<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">relay as well.&nbsp; =
<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I think we should also ask in our liaison =
for=20
  clarification if the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">S-VLAN translation can be valid by itself =
i.e. as a=20
  label agnostic to<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">the MAC so there is no=20
  confusion.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Don<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; -----Original=20
  Message-----<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; From: [e-mail]=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; All,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; The IETF received an unsolicited =
liaison on the=20
  subject of <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; 802.1 =
Ethernet<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; You can see the liaison=20
  at<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt;=20
  =
https://datatracker.ietf.org/documents/LIAISON/file358.pdf<o:p></o:p></SP=
AN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; The participants on the GELS mailing =
list have=20
  requested that <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; we respond to this to clarify an=20
  issue.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Here is the draft of a liaison that we =
proposed=20
  to send. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Please shout at once if you have any =
concerns=20
  with this <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; liaison. I intend to ask Bert to send =
it on=20
  Monday of next week.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <st1:City w:st=3D"on"><st1:place=20
  w:st=3D"on">Adrian</st1:place></st1:City><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; =3D=3D=3D<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Subject: Response to your liaison "Use =
of IEEE=20
  802.1Q VLAN tags"<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Date: Sep =
2006<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; To: =
IEEE802.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tony =
Jeffree, IEEE=20
  802.1 WG Chair, [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; From: Bert Wijnen, IETF liaison to IETF =
liaison=20
  to IEEE 802.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Adrian Farrel, IETF CCAMP Working Group =
co-chair<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Deborah Brungard, IETF CCAMP Working Group=20
  co-chair<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Cc: Bernard Aboba=20
  [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ross=20
  Callon [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bill=20
  Fenner [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CCAMP=20
  mailing list [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GELS=20
  mailing list&nbsp; [e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Thank you for your very informative and =

  clarifying liaison on <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; "Use of IEEE 802.1Q VLAN=20
  tags".<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; We have a question arising from this =
liaison and=20
  our reading <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; of the relevant standards documents as=20
  follows.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; The liaison says: "Translation of =
802.1Q S-VLAN=20
  tags (with 12 <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; bit VIDs) is supported at S-tagged =
service=20
  interfaces, as an <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; option, by the IEEE Std 802.1ad =
Provider Bridging=20
  amendment <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; to IEEE Std =
802.1Q."<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; While this text in itself is clear it =
leaves open=20
  the <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; question of whether "S-tagged Service =
interfaces"=20
  is the only <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; type of interface where Translation of =
802.1Q=20
  S-VLAN tags is <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; supported.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; It is our understanding that IEEE Std =
802.1ad=20
  does not <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; preclude the translation of 802.1Q =
S-VLAN tags at=20
  any <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; S-tagged interface. Thus, this =
translation would=20
  be allowed <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; at Provider Network Ports, not just at =
Customer=20
  Network Ports.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Can you please confirm whether this is =
the=20
  correct <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; interpretation of the IEEE Std 802.1ad =
amendment=20
  to the IEEE <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Std =
802.1Q?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Many =
thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Bert Wijnen, IETF liaison to IEEE=20
  802.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Adrian Farrel and Deborah Brungard, =
CCAMP Working=20
  Group co-chairs<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">_______________________________________________<o:p></o:p></SPAN></=
FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">gels mailing =
list<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">[e-mail]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">https://rtg.ietf.org/mailman/listinfo/gels<o:p></o:p></SPAN></FONT>=
</P>
  <P class=3DMsoPlainText dir=3Dltr><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C6DD6D.1821739E--



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Sep 2006 10:40:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD72.790106C1"
Subject: RE: Proposed liaison response to IEEE
Date: Thu, 21 Sep 2006 13:38:16 +0200
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuA=
From: "Nurit Sprecher" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Wijnen, Bert \(Bert\)" <[e-mail]>, <[e-mail]>, "Nurit Sprecher" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DD72.790106C1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I think it is a good idea to send the liaison to the IEEE and get once
and for all a clear statement that the s-vid translation is supported on
each provider bridge port.=20

=20

In addition, the IEEE has recognized that MAC learning is not required
for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes
this extension in section 8.7.=20

=20

" The Learning Process receives the source MAC Addresses and VIDs of
received frames from the

Forwarding Process, following the application of the ingress rules
(8.6.2). It shall create or update a

Dynamic Filtering Entry (8.8.3) that specifies the reception Port for
the frame's source address and VID, if

and only if the source address is an Individual Address, i.e., is not a
Group Address, the resulting number of

entries would not exceed the capacity of the Filtering Database, and the
filtering utility criteria for the

receiving Bridge Port are met."

The enhanced filtering utility criteria "are satisfied if at least one
VLAN that uses the FID includes the reception Port and at least one
other Port with a Port State of Learning or Forwarding in its member
set, and: a) The operPointToPointMAC parameter is false for the
reception Port; or b) Ingress to the VLAN is permitted through a third
Port. NOTE -The third port can, but is not required to be in the member
set.".=20

=20

I think it is clearly stated, but if it is required to ask the IEEE
about the context of forwarding based on a destination MAC, I suggest
being more precise and specify that we are talking on point-to-point
connections.

=20

Regards,

Nurit.

=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Don Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian Farrel; [e-mail]
Cc: [e-mail]; Wijnen, Bert (Bert)
Subject: RE: Proposed liaison response to IEEE

=20

Hi Adrian

=20

The Liaison looks good however it does not capture a comment I made.  =20

=20

My understanding of the S-VLAN translation in IEEE documents and the

liaison is that the translation is valid in the context of forwarding

based on a destination MAC. My interpretation is that V-LAN is optional

MAC is not. If I am correct VLAN translation as specified is not equal

to Label switching. The Liaison is clear about not just the format of

'packets on the wire' but the relationship to the entities such as MAC

relay as well. =20

=20

I think we should also ask in our liaison for clarification if the

S-VLAN translation can be valid by itself i.e. as a label agnostic to

the MAC so there is no confusion.

=20

Thanks,

Don

=20

=20

> -----Original Message-----

> From: [e-mail]=20

> All,

>=20

> The IETF received an unsolicited liaison on the subject of=20

> 802.1 Ethernet

>=20

> You can see the liaison at

> https://datatracker.ietf.org/documents/LIAISON/file358.pdf

>=20

> The participants on the GELS mailing list have requested that=20

> we respond to this to clarify an issue.

>=20

> Here is the draft of a liaison that we proposed to send.=20

> Please shout at once if you have any concerns with this=20

> liaison. I intend to ask Bert to send it on Monday of next week.

>=20

> Thanks,

> Adrian

> =3D=3D=3D

> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags"

>=20

> Date: Sep 2006

> To: IEEE802.1

>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]

>=20

> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1

>           Adrian Farrel, IETF CCAMP Working Group co-chair

>           Deborah Brungard, IETF CCAMP Working Group co-chair

>=20

> Cc: Bernard Aboba [e-mail]

>        Ross Callon [e-mail]

>        Bill Fenner [e-mail]

>        CCAMP mailing list [e-mail]

>        GELS mailing list  [e-mail]

>=20

> Thank you for your very informative and clarifying liaison on=20

> "Use of IEEE 802.1Q VLAN tags".

>=20

> We have a question arising from this liaison and our reading=20

> of the relevant standards documents as follows.

>=20

> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20

> bit VIDs) is supported at S-tagged service interfaces, as an=20

> option, by the IEEE Std 802.1ad Provider Bridging amendment=20

> to IEEE Std 802.1Q."

>=20

> While this text in itself is clear it leaves open the=20

> question of whether "S-tagged Service interfaces" is the only=20

> type of interface where Translation of 802.1Q S-VLAN tags is=20

> supported.

>=20

> It is our understanding that IEEE Std 802.1ad does not=20

> preclude the translation of 802.1Q S-VLAN tags at any=20

> S-tagged interface. Thus, this translation would be allowed=20

> at Provider Network Ports, not just at Customer Network Ports.

>=20

> Can you please confirm whether this is the correct=20

> interpretation of the IEEE Std 802.1ad amendment to the IEEE=20

> Std 802.1Q?

>=20

> Many thanks,

>=20

> Bert Wijnen, IETF liaison to IEEE 802.1

> Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs

>=20

>=20

>=20

>=20

=20

_______________________________________________

gels mailing list

[e-mail]

https://rtg.ietf.org/mailman/listinfo/gels

=20


------_=_NextPart_001_01C6DD72.790106C1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 69.6pt 1.0in 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1 dir=3DRTL>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>I think it is a good idea to send the liaison =
to the
IEEE and get once and for all a clear statement that the s-vid =
translation is supported
on each provider bridge port. <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>In addition, the IEEE has recognized that =
<b><span
style=3D'font-weight:bold'>MAC learning is not required for =
point-to-point VLANs
in a bridge</span></b>. <b><span style=3D'font-weight:bold'>The 802.1Q =
rev-5 already
includes this extension in section 8.7</span></b>. =
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&quot; The Learning Process receives the =
source MAC
Addresses and VIDs of received frames from =
the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Forwarding Process, following the application =
of the
ingress rules (8.6.2). <b><span style=3D'font-weight:bold'>It shall =
create or update
a<o:p></o:p></span></b></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><b><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-weight:bold'>Dynamic Filtering Entry =
(8.8.3) that
specifies the <st1:place w:st=3D"on"><st1:PlaceName =
w:st=3D"on">reception</st1:PlaceName>
 <st1:PlaceType w:st=3D"on">Port</st1:PlaceType></st1:place> for the
frame&#8217;s source address and VID, =
if<o:p></o:p></span></font></b></p>

<p class=3DMsoPlainText dir=3DLTR><b><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-weight:bold'>and only if =
</span></font></b>the
source address is an Individual Address, i.e., is not a Group Address, =
the
resulting number of<o:p></o:p></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>entries would not exceed the capacity of the =
Filtering
Database, <b><span style=3D'font-weight:bold'>and the filtering utility =
criteria
for the<o:p></o:p></span></b></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><b><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-weight:bold'>receiving <st1:place =
w:st=3D"on"><st1:PlaceType
 w:st=3D"on">Bridge</st1:PlaceType> <st1:PlaceType =
w:st=3D"on">Port</st1:PlaceType></st1:place>
are met.&quot;</span></font></b><b><span lang=3DHE dir=3DRTL =
style=3D'font-weight:
bold'><o:p></o:p></span></b></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>The enhanced filtering utility criteria =
&quot;are
satisfied if at least one VLAN that uses the FID includes the reception =
Port
and at least one other Port with a Port State of Learning or Forwarding =
in its
member set, and: a) The operPointToPointMAC parameter is false for the
reception Port; or b) Ingress to the VLAN is permitted through a third =
Port. NOTE
&#8212;The third port can, but is not required to be in the member =
set.&quot;. <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>I think it is clearly stated, but if it is =
required to
ask the IEEE about the context of forwarding based on a destination MAC, =
<b><span
style=3D'font-weight:bold'>I suggest being more precise and specify that =
we are
talking on</span></b> <b><span style=3D'font-weight:bold'>point-to-point
connections.<o:p></o:p></span></b></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><b><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-weight:bold'><o:p>&nbsp;</o:p></span></fon=
t></b></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Nurit.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>-----Original Message-----<br>
From: [e-mail] [mailto:[e-mail]] On =
Behalf Of
Don Fedyk<br>
Sent: Wednesday, September 20, 2006 23:16<br>
To: Adrian Farrel; [e-mail]<br>
Cc: [e-mail]; Wijnen, Bert (Bert)<br>
Subject: RE: Proposed liaison response to IEEE</span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Hi Adrian<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>The Liaison looks good however it does not =
capture a
comment I made.&nbsp;&nbsp; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>My understanding of the S-VLAN translation in =
IEEE
documents and the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>liaison is that the translation is valid in =
the
context of forwarding<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>based on a destination MAC. My interpretation =
is that
V-LAN is optional<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>MAC is not. If I am correct VLAN translation =
as
specified is not equal<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>to Label switching. The Liaison is clear =
about not
just the format of<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>'packets on the wire' but the relationship to =
the
entities such as MAC<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>relay as well.&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>I think we should also ask in our liaison for
clarification if the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>S-VLAN translation can be valid by itself =
i.e. as a
label agnostic to<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>the MAC so there is no =
confusion.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>Don<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; From: [e-mail] =
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; All,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; The IETF received an unsolicited liaison =
on the
subject of <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; 802.1 =
Ethernet<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; You can see the liaison =
at<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; =
https://datatracker.ietf.org/documents/LIAISON/file358.pdf<o:p></o:p></sp=
an></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; The participants on the GELS mailing =
list have
requested that <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; we respond to this to clarify an =
issue.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Here is the draft of a liaison that we =
proposed
to send. <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Please shout at once if you have any =
concerns
with this <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; liaison. I intend to ask Bert to send it =
on
Monday of next week.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Adrian</st1:place></st1:City><o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; =3D=3D=3D<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Subject: Response to your liaison =
&quot;Use of
IEEE 802.1Q VLAN tags&quot;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Date: Sep =
2006<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; To: =
IEEE802.1<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tony =
Jeffree, IEEE
802.1 WG Chair, [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; From: Bert Wijnen, IETF liaison to IETF =
liaison
to IEEE 802.1<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
Adrian Farrel, IETF CCAMP Working Group =
co-chair<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
Deborah Brungard, IETF CCAMP Working Group =
co-chair<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Cc: Bernard Aboba =
[e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Ross
Callon [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Bill
Fenner [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 CCAMP
mailing list [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 GELS
mailing list&nbsp; [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Thank you for your very informative and
clarifying liaison on <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; &quot;Use of IEEE 802.1Q VLAN =
tags&quot;.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; We have a question arising from this =
liaison and
our reading <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; of the relevant standards documents as =
follows.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; The liaison says: &quot;Translation of =
802.1Q
S-VLAN tags (with 12 <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; bit VIDs) is supported at S-tagged =
service
interfaces, as an <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; option, by the IEEE Std 802.1ad Provider =
Bridging
amendment <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; to IEEE Std =
802.1Q.&quot;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; While this text in itself is clear it =
leaves open
the <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; question of whether &quot;S-tagged =
Service
interfaces&quot; is the only <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; type of interface where Translation of =
802.1Q
S-VLAN tags is <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; supported.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; It is our understanding that IEEE Std =
802.1ad
does not <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; preclude the translation of 802.1Q =
S-VLAN tags at
any <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; S-tagged interface. Thus, this =
translation would
be allowed <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; at Provider Network Ports, not just at =
Customer
Network Ports.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Can you please confirm whether this is =
the
correct <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; interpretation of the IEEE Std 802.1ad =
amendment
to the IEEE <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Std 802.1Q?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Many =
thanks,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Bert Wijnen, IETF liaison to IEEE =
802.1<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; Adrian Farrel and Deborah Brungard, =
CCAMP Working
Group co-chairs<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>______________________________________________=
_<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>gels mailing =
list<o:p></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>[e-mail]<o:p></o:p></span></font></p>=


<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'>https://rtg.ietf.org/mailman/listinfo/gels<o:p=
></o:p></span></font></p>

<p class=3DMsoPlainText dir=3DLTR><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6DD72.790106C1--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Sep 2006 21:17:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed liaison response to IEEE
Date: Wed, 20 Sep 2006 17:15:44 -0400
Message-ID: <[e-mail]>
Thread-Topic: Proposed liaison response to IEEE
Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CA
From: "Don Fedyk" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Wijnen, Bert \(Bert\)" <[e-mail]>

Hi Adrian

The Liaison looks good however it does not capture a comment I made.  =20

My understanding of the S-VLAN translation in IEEE documents and the
liaison is that the translation is valid in the context of forwarding
based on a destination MAC. My interpretation is that V-LAN is optional
MAC is not. If I am correct VLAN translation as specified is not equal
to Label switching. The Liaison is clear about not just the format of
'packets on the wire' but the relationship to the entities such as MAC
relay as well. =20

I think we should also ask in our liaison for clarification if the
S-VLAN translation can be valid by itself i.e. as a label agnostic to
the MAC so there is no confusion.

Thanks,
Don


> -----Original Message-----
> From: [e-mail]=20
> All,
>=20
> The IETF received an unsolicited liaison on the subject of=20
> 802.1 Ethernet
>=20
> You can see the liaison at
> https://datatracker.ietf.org/documents/LIAISON/file358.pdf
>=20
> The participants on the GELS mailing list have requested that=20
> we respond to this to clarify an issue.
>=20
> Here is the draft of a liaison that we proposed to send.=20
> Please shout at once if you have any concerns with this=20
> liaison. I intend to ask Bert to send it on Monday of next week.
>=20
> Thanks,
> Adrian
> =3D=3D=3D
> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags"
>=20
> Date: Sep 2006
> To: IEEE802.1
>      Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]
>=20
> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
>           Adrian Farrel, IETF CCAMP Working Group co-chair
>           Deborah Brungard, IETF CCAMP Working Group co-chair
>=20
> Cc: Bernard Aboba [e-mail]
>        Ross Callon [e-mail]
>        Bill Fenner [e-mail]
>        CCAMP mailing list [e-mail]
>        GELS mailing list  [e-mail]
>=20
> Thank you for your very informative and clarifying liaison on=20
> "Use of IEEE 802.1Q VLAN tags".
>=20
> We have a question arising from this liaison and our reading=20
> of the relevant standards documents as follows.
>=20
> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20
> bit VIDs) is supported at S-tagged service interfaces, as an=20
> option, by the IEEE Std 802.1ad Provider Bridging amendment=20
> to IEEE Std 802.1Q."
>=20
> While this text in itself is clear it leaves open the=20
> question of whether "S-tagged Service interfaces" is the only=20
> type of interface where Translation of 802.1Q S-VLAN tags is=20
> supported.
>=20
> It is our understanding that IEEE Std 802.1ad does not=20
> preclude the translation of 802.1Q S-VLAN tags at any=20
> S-tagged interface. Thus, this translation would be allowed=20
> at Provider Network Ports, not just at Customer Network Ports.
>=20
> Can you please confirm whether this is the correct=20
> interpretation of the IEEE Std 802.1ad amendment to the IEEE=20
> Std 802.1Q?
>=20
> Many thanks,
>=20
> Bert Wijnen, IETF liaison to IEEE 802.1
> Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Sep 2006 19:39:05 +0000
Message-ID: <0d9701c6dcec$4a9948b0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Wijnen, Bert \(Bert\)" <[e-mail]>
Subject: Proposed liaison response to IEEE
Date: Wed, 20 Sep 2006 20:37:49 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

All,

The IETF received an unsolicited liaison on the subject of 802.1 Ethernet

You can see the liaison at 
https://datatracker.ietf.org/documents/LIAISON/file358.pdf

The participants on the GELS mailing list have requested that we respond to 
this to clarify an issue.

Here is the draft of a liaison that we proposed to send. Please shout at 
once if you have any concerns with this liaison. I intend to ask Bert to 
send it on Monday of next week.

Thanks,
Adrian
===
Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags"

Date: Sep 2006
To: IEEE802.1
     Tony Jeffree, IEEE 802.1 WG Chair, [e-mail]

From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1
          Adrian Farrel, IETF CCAMP Working Group co-chair
          Deborah Brungard, IETF CCAMP Working Group co-chair

Cc: Bernard Aboba [e-mail]
       Ross Callon [e-mail]
       Bill Fenner [e-mail]
       CCAMP mailing list [e-mail]
       GELS mailing list  [e-mail]

Thank you for your very informative and clarifying liaison on "Use of
IEEE 802.1Q VLAN tags".

We have a question arising from this liaison and our reading of the
relevant standards documents as follows.

The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 bit VIDs)
is supported at S-tagged service interfaces, as an option, by the IEEE
Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q."

While this text in itself is clear it leaves open the question of
whether "S-tagged Service interfaces" is the only type of interface
where Translation of 802.1Q S-VLAN tags is supported.

It is our understanding that IEEE Std 802.1ad does not preclude the
translation of 802.1Q S-VLAN tags at any S-tagged interface. Thus, this
translation would be allowed at Provider Network Ports, not just at
Customer Network Ports.

Can you please confirm whether this is the correct interpretation of the
IEEE Std 802.1ad amendment to the IEEE Std 802.1Q?

Many thanks,

Bert Wijnen, IETF liaison to IEEE 802.1
Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs





Envelope-to: [e-mail]
Delivery-date: Wed, 20 Sep 2006 18:17:03 +0000
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'GMPLS Based Segment Recovery' to Proposed Standard  (draft-ietf-ccamp-gmpls-segment-recovery) 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 20 Sep 2006 14:16:41 -0400

The IESG has received a request from the Common Control and Measurement 
Plane WG to consider the following document:

- 'GMPLS Based Segment Recovery '
   <draft-ietf-ccamp-gmpls-segment-recovery-02.txt> as a Proposed Standard


The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2006-10-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Sep 2006 18:16:44 +0000
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'RSVP-TE Extensions in support of End-to-End  Generalized Multi-Protocol Label Switching (GMPLS)-based  Recovery' to Proposed Standard  (draft-ietf-ccamp-gmpls-recovery-e2e-signaling) 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 20 Sep 2006 14:15:50 -0400

The IESG has received a request from the Common Control and Measurement 
Plane WG to consider the following document:

- 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol

    Label Switching (GMPLS)-based Recovery '
   <draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2006-10-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Sep 2006 18:16:35 +0000
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Routing extensions for discovery of Multiprotocol  (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh  membership' to Proposed Standard (draft-ietf-ccamp-automesh) 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 20 Sep 2006 14:14:35 -0400

The IESG has received a request from the Common Control and Measurement 
Plane WG to consider the following document:

- 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch

   Router (LSR) Traffic Engineering (TE) mesh membership '
   <draft-ietf-ccamp-automesh-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2006-10-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-02.txt




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Sep 2006 03:04:13 +0000
To: "Olufemi Komolafe" <[e-mail]>
Cc: "ccamp" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 20 Sep 2006 10:57:59 +0800
Content-Type: multipart/mixed; boundary="=_mixed 00109675482571EF_="

--=_mixed 00109675482571EF_=
Content-Type: multipart/alternative; boundary="=_alternative 00109677482571EF_="


--=_alternative 00109677482571EF_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGVsbG8sIGV2ZXJ5b25lIQ0KDQpXZSBoYXZlIHB1dCBmb3J3YXJkIGEgbWVjaGFuaXNtIHRvIHNv
bHZlIHRoaXMgcHJvYmxlbSBpbiBvdXIgDQpkcmFmdCAiZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5v
ZGVzLXJzdnAtcmVzdGFydC0wMCIgbGFzdCB5ZWFyLg0KDQpXZSB0aGluayB0aGF0IGlmIG11bHRp
cGxlIGFkamFjZW50IG5vZGVzIHJlc3RhcnRlZCBuZWFybHkgYXQgDQp0aGUgc2FtZSB0aW1lLCB0
aGVzZSBub2RlcyBjYW5ub3QgbGVhcm4gYWJvdXQgdGhlIEdSIGNhcGFiaWxpdHkgDQpmcm9tIGVh
Y2ggb3RoZXIuIA0KDQpUaGUga2V5IG9mIHRoaXMgcHJvYmxlbSBpcyB0aGF0IGhvdyByZXN0YXJ0
ZWQgbm9kZSBhY3RpdmVseSANCmluZm9ybSBpdHMgR1IoR3JhY2VmdWwgUmVzdGFydCkgY2FwYWJp
bGl0eSB0byBuZWlnaGJvciBub2RlcywgDQplc3BlY2lhbGx5IHNvbWUgbmVpZ2hib3Igbm9kZXMg
YXJlIHJlc3RhcnRlZCBub2RlcyB0b28uDQoNCklmIHlvdSBjb25jZXJuIG91ciBtZWNoYW5pc20s
IHBsZWFzZSByZWFkIG91ciBkcmFmdCBmb3IgZGV0YWlsLg0KDQoNCg0KDQpSZWdhcmQsDQpKaWFu
ZyBXZWlsaWFuDQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Lg0KQWRkOiAgIE5vLjY4IFppamluZ2h1YSBSZCxZdWh1YXRhaSBEaXN0cmljdCwgDQogICAgICAg
IE5hbmppbmcuIFAuUi5DaGluYS4gDQpaaXA6ICAgMjEwMDEyIA0KVGVsOiAgIDAwODYtMjUtNTI4
NzE2NDQgDQpNYWlsOiAgamlhbmcud2VpbGlhbkB6dGUuY29tLmNuIA0KLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIA0KDQoNCg0KDQoNCiJPbHVmZW1pIEtvbW9s
YWZlIiA8ZmVtaUBkY3MuZ2xhLmFjLnVrPg0Kt6K8/sjLo7ogb3duZXItY2NhbXBAb3BzLmlldGYu
b3JnDQoNCjIwMDYtMDktMTkgMjA6NDUNCiANCiAgICAgICAgytW8/sjLo7ogICAgICAgIDxkYW5s
aUBodWF3ZWkuY29tPiwgPGdqaGhpdEBodWF3ZWkuY29tPg0KICAgICAgICCzrcvNo7ogICJjY2Ft
cCIgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCiAgICAgICAg1vfM4qO6ICBSRTogQ29tbWVudHMgb24g
ZHJhZnQtbGktY2NhbXAtbXVsdGlub2Rlcy1nci1wcm9jLTAwLnR4dCwNCg0KDQpIaSwNCiANCldo
aWxlIHJlYWRpbmcgdGhpcyBkcmFmdCBpdCBvY2N1cnJlZCB0byBtZSB0aGF0IHBlcmhhcHMgaXQg
bWlnaHQgYmUgbW9yZSANCnVzZWZ1bCB0byBhcHByb2FjaCB0aGlzIHRvcGljIGZyb20gdGhlIHBl
cnNwZWN0aXZlIG9mIKGwV2hhdCBjYW4gZ28gd3JvbmcgDQpkdXJpbmcgZ3JhY2VmdWwgcmVzdGFy
dCwgd2hhdCBhcmUgdGhlIGNvbnNlcXVlbmNlcyBhbmQgaG93IGNhbiBpdCBiZSANCmZpeGVkP6Gx
IHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZSBuYXJyb3dlciB0b3BpYyBvZiBtdWx0aXBsZSAN
CnNpbXVsdGFuZW91cyBub2RhbCBmYXVsdHMuDQogDQpGb3IgZXhhbXBsZSwgU2NlbmFyaW8gMSBp
biB0aGUgZHJhZnQgbWF5IGJlIGludGVycHJldGVkIGFzIKGwV2hhdCBzaG91bGQgDQpoYXBwZW4g
aWYgYSAobm9uLWluZ3Jlc3MpIHJlc3RhcnRpbmcgbm9kZSBmYWlscyB0byBnZXQgYSBSZWNvdmVy
eVBhdGggDQptZXNzYWdlIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3VyP6GxLCBTY2VuYXJp
byAyIGlzIKGwV2hhdCBzaG91bGQgDQpoYXBwZW4gaWYgYSAobm9uLWluZ3Jlc3MpIHJlc3RhcnRp
bmcgbm9kZSBmYWlscyB0byBnZXQgYSBQYXRoIG1lc3NhZ2UgZnJvbSANCml0cyB1cHN0cmVhbSBu
ZWlnaGJvdXI/obEgYW5kIHNvIG9uLiAgV2hldGhlciBlYWNoIG9mIHRoZXNlIHNjZW5hcmlvcyAN
CmFyaXNlcyBkdWUgdG8gbXVsdGlwbGUgc2ltdWx0YW5lb3VzIG5vZGFsIGZhdWx0cyAoYXMgaW4g
dGhlIGRyYWZ0KSBvciBhbnkgDQpvdGhlciByZWFzb24gKGUuZy4gYSBzdWJzZXF1ZW50IGNvbnRy
b2wgY2hhbm5lbCBmYWlsdXJlLCByZXN0YXJ0aW5nIG5vZGUgDQpiZWluZyBpbnVuZGF0ZWQgd2l0
aCBtZXNzYWdlcyBldGMuKSBpcywgaW4gbXkgb3Bpbmlvbiwgc2Vjb25kYXJ5LiAgSSB0aGluayAN
CnRoZSBrZXkgdGhpbmcgaXMgdG8gaWRlbnRpZnkgdGhlIHBvdGVudGlhbCBwcm9ibGVtcyBhbmQg
c3VnZ2VzdCANCmFwcHJvcHJpYXRlIHJlbWVkaWFsIGFjdGlvbnMsIHdoZXJlIHRoZSBhdXRob3Jz
IHRoaW5rIGV4aXN0aW5nIA0KZG9jdW1lbnRhdGlvbiBpcyBpbnN1ZmZpY2llbnQsIHJhdGhlciB0
aGFuIGZvY3VzaW5nIG9uIDUgZGlmZmVyZW50IA0KcGVybXV0YXRpb25zIG9mIG11bHRpcGxlIG5v
ZGUgZ3JhY2VmdWwgcmVzdGFydC4gDQogDQpSZWdhcmRzLA0KRmVtaQ0KIA0KIA0KDQpGcm9tOiBv
d25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmdd
IE9uIEJlaGFsZiANCk9mIFphZmFyIEFsaSAoemFsaSkNClNlbnQ6IDEwIEp1bHkgMjAwNiAwNDow
NA0KVG86IGRhbmxpQGh1YXdlaS5jb207IGdqaGhpdEBodWF3ZWkuY29tDQpDYzogY2NhbXANClN1
YmplY3Q6IENvbW1lbnRzIG9uIGRyYWZ0LWxpLWNjYW1wLW11bHRpbm9kZXMtZ3ItcHJvYy0wMC50
eHQsIA0KIA0KRGVhciBBdXRob3JzLCANCiANClRoaXMgaXMgRGVqYS12dSB0byBtZS4uLi4gDQog
DQpEcmFmdCBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtcmVzdGFydC1leHQtMDUudHh0IGFjdHVhbGx5
IGhhZCBhIHNlY3Rpb24gb24gDQptdWx0aXBsZSBub2RlIHJlc3RhcnQgY2FzZSBhbmQgd2FzIHJl
amVjdGVkIGJ5IHRoZSBXRyBhcyBhZGRyZXNzaW5nIA0KbXVsdGlwbGUgbm9kZSByZXN0YXJ0IGNh
c2UgaXMgTk9UIGEgZ29hbCAoc3VmZmVycyBmcm9tIHRoZSBsYXcgb2YgDQpkaW1pbmlzaGluZyBy
ZXR1cm4pLiBJbiBvdGhlciB3b3JkcyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0aGUgSUQt
IA0KIA0KICAgIltHUi1FWFRdIGFsc28gZXh0ZW5kcyB0aGUgSGVsbG8gbWVzc2FnZSB0byBleGNo
YW5nZSBpbmZvcm1hdGlvbiBhYm91dCANCiAgIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgdGhlIFJl
Y292ZXJ5UGF0aCBtZXNzYWdlLiANCiAgIFRoZSBleGFtcGxlcyBhbmQgcHJvY2VkdXJlcyBpbiBb
R1ItRVhUXSBmb2N1cyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgYSANCiAgIHNpbmdsZSBub2RlIHJl
c3RhcnQgd2hlbiBhZGphY2VudCBuZXR3b3JrIG5vZGVzIGFyZSBvcGVyYXRpdmUuIA0KICAgQWx0
aG91Z2ggdGhlIHByb2NlZHVyZXMgYXJlIGVxdWFsbHkgYXBwbGljYWJsZSB0byBtdWx0aS1ub2Rl
IHJlc3RhcnRzLCANCiAgIG5vIGRldGFpbGVkIGV4cGxhbmF0aW9uIGlzIHByb3ZpZGVkLiIgDQog
DQppcyBub3QgYWNjdXJhdGUuIFBsZWFzZSBzZWUgc2VjdGlvbiA0IG9uIHRoZSBlYXJsaWVyIHZl
cnNpb24gb2YgdGhlIA0KW0dSLUVYVF0sIA0KaHR0cDovL3d3dy5mYXFzLm9yZy9mdHAvcHViL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1yYWhtYW4tY2NhbXAtcnN2cC1yZXN0YXJ0LWV4dGVuc2lvbnMt
MDAudHh0DQouIA0KIA0KVGhhbmtzDQogDQpSZWdhcmRzLi4uIFphZmFyIA0KIA0KDQoNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg
SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu
IHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0
aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50
cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJl
IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh
dGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3
aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNl
IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g
DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg
dGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0
aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt
ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt
U3BhbSANCnN5c3RlbS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6
IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0
eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp
cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt
YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u
dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu
eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk
IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0
aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy
b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz
IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl
bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt
IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K
--=_alternative 00109677482571EF_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLCBldmVyeW9uZSE8L2Zv
bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGhhdmUgcHV0
IGZvcndhcmQgYSBtZWNoYW5pc20gdG8gc29sdmUNCnRoaXMgcHJvYmxlbSBpbiBvdXIgPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5kcmFmdCAmcXVvdDtkcmFmdC1q
aWFuLWNjYW1wLW11bHRpbm9kZXMtcnN2cC1yZXN0YXJ0LTAwJnF1b3Q7DQpsYXN0IHllYXIuPC9m
b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSB0aGluayB0
aGF0IGlmIG11bHRpcGxlIGFkamFjZW50IG5vZGVzDQpyZXN0YXJ0ZWQgbmVhcmx5IGF0IDwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIHNhbWUgdGltZSwgdGhl
c2Ugbm9kZXMgY2Fubm90IGxlYXJuDQphYm91dCB0aGUgR1IgY2FwYWJpbGl0eSA8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZyb20gZWFjaCBvdGhlci4gPC9mb250
Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUga2V5IG9mIHRo
aXMgcHJvYmxlbSBpcyB0aGF0IGhvdw0KcmVzdGFydGVkIG5vZGUgYWN0aXZlbHkgPC9mb250Pg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbmZvcm0gaXRzIEdSKEdyYWNlZnVs
IFJlc3RhcnQpIGNhcGFiaWxpdHkNCnRvIG5laWdoYm9yIG5vZGVzLCA8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmVzcGVjaWFsbHkgc29tZSBuZWlnaGJvciBub2Rl
cyBhcmUgcmVzdGFydGVkDQpub2RlcyB0b28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB5b3UgY29uY2VybiBvdXIgbWVjaGFuaXNtLCBwbGVhc2UN
CnJlYWQgb3VyIGRyYWZ0IGZvciBkZXRhaWwuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmQsPGJyPg0KSmlhbmcg
V2VpbGlhbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Li4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48YnI+DQpBZGQ6ICZuYnNw
OyBOby42OCBaaWppbmdodWEgUmQsWXVodWF0YWkgRGlzdHJpY3QsIDxicj4NCiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtOYW5qaW5nLiBQLlIuQ2hpbmEuIDxicj4NClppcDogJm5ic3A7IDIx
MDAxMiA8YnI+DQpUZWw6ICZuYnNwOyAwMDg2LTI1LTUyODcxNjQ0IDxicj4NCk1haWw6ICZuYnNw
O2ppYW5nLndlaWxpYW5AenRlLmNvbS5jbiA8YnI+DQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4gPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh
YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48Zm9udCBzaXplPTEg
ZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7T2x1ZmVtaSBLb21vbGFmZSZxdW90OyAmbHQ7ZmVt
aUBkY3MuZ2xhLmFjLnVrJmd0OzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPreivP7Iy6O6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvZm9udD4NCjxicj4N
CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA2LTA5LTE5IDIwOjQ1PC9mb250
Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IMrVvP7Iy6O6DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm
bHQ7ZGFubGlAaHVhd2VpLmNvbSZndDssICZsdDtnamhoaXRAaHVhd2VpLmNvbSZndDs8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyCzrcvNo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2NjYW1wJnF1
b3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm
YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg1vfM4qO6DQombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTogQ29tbWVudHMgb24gZHJhZnQtbGktY2NhbXAtbXVs
dGlub2Rlcy1nci1wcm9jLTAwLnR4dCw8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5IaSw8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPldoaWxlIHJlYWRpbmcgdGhpcyBkcmFmdCBpdCBv
Y2N1cnJlZA0KdG8gbWUgdGhhdCBwZXJoYXBzIGl0IG1pZ2h0IGJlIG1vcmUgdXNlZnVsIHRvIGFw
cHJvYWNoIHRoaXMgdG9waWMgZnJvbQ0KdGhlIHBlcnNwZWN0aXZlIG9mIKGwV2hhdCBjYW4gZ28g
d3JvbmcgZHVyaW5nIGdyYWNlZnVsIHJlc3RhcnQsIHdoYXQgYXJlDQp0aGUgY29uc2VxdWVuY2Vz
IGFuZCBob3cgY2FuIGl0IGJlIGZpeGVkP6GxIHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZQ0K
bmFycm93ZXIgdG9waWMgb2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIG5vZGFsIGZhdWx0cy48L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZvciBleGFtcGxlLCBT
Y2VuYXJpbyAxIGluIHRoZQ0KZHJhZnQgbWF5IGJlIGludGVycHJldGVkIGFzIKGwV2hhdCBzaG91
bGQgaGFwcGVuIGlmIGEgKG5vbi1pbmdyZXNzKSByZXN0YXJ0aW5nDQpub2RlIGZhaWxzIHRvIGdl
dCBhIFJlY292ZXJ5UGF0aCBtZXNzYWdlIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3VyP6Gx
LA0KU2NlbmFyaW8gMiBpcyChsFdoYXQgc2hvdWxkIGhhcHBlbiBpZiBhIChub24taW5ncmVzcykg
cmVzdGFydGluZyBub2RlDQpmYWlscyB0byBnZXQgYSBQYXRoIG1lc3NhZ2UgZnJvbSBpdHMgdXBz
dHJlYW0gbmVpZ2hib3VyP6GxIGFuZCBzbyBvbi4NCiZuYnNwO1doZXRoZXIgZWFjaCBvZiB0aGVz
ZSBzY2VuYXJpb3MgYXJpc2VzIGR1ZSB0byBtdWx0aXBsZSBzaW11bHRhbmVvdXMNCm5vZGFsIGZh
dWx0cyAoYXMgaW4gdGhlIGRyYWZ0KSBvciBhbnkgb3RoZXIgcmVhc29uIChlLmcuIGEgc3Vic2Vx
dWVudCBjb250cm9sDQpjaGFubmVsIGZhaWx1cmUsIHJlc3RhcnRpbmcgbm9kZSBiZWluZyBpbnVu
ZGF0ZWQgd2l0aCBtZXNzYWdlcyBldGMuKSBpcywNCmluIG15IG9waW5pb24sIHNlY29uZGFyeS4g
Jm5ic3A7SSB0aGluayB0aGUga2V5IHRoaW5nIGlzIHRvIGlkZW50aWZ5IHRoZQ0KcG90ZW50aWFs
IHByb2JsZW1zIGFuZCBzdWdnZXN0IGFwcHJvcHJpYXRlIHJlbWVkaWFsIGFjdGlvbnMsIHdoZXJl
IHRoZQ0KYXV0aG9ycyB0aGluayBleGlzdGluZyBkb2N1bWVudGF0aW9uIGlzIGluc3VmZmljaWVu
dCwgcmF0aGVyIHRoYW4gZm9jdXNpbmcNCm9uIDUgZGlmZmVyZW50IHBlcm11dGF0aW9ucyBvZiBt
dWx0aXBsZSBub2RlIGdyYWNlZnVsIHJlc3RhcnQuICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZlbWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z
IGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGRpdiBhbGlnbj1j
ZW50ZXI+DQo8YnI+DQo8aHI+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+
PGI+RnJvbTo8L2I+IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1w
QG9wcy5pZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WmFmYXIgQWxpICh6YWxpKTxiPjxi
cj4NClNlbnQ6PC9iPiAxMCBKdWx5IDIwMDYgMDQ6MDQ8Yj48YnI+DQpUbzo8L2I+IGRhbmxpQGh1
YXdlaS5jb207IGdqaGhpdEBodWF3ZWkuY29tPGI+PGJyPg0KQ2M6PC9iPiBjY2FtcDxiPjxicj4N
ClN1YmplY3Q6PC9iPiBDb21tZW50cyBvbiBkcmFmdC1saS1jY2FtcC1tdWx0aW5vZGVzLWdyLXBy
b2MtMDAudHh0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RGVhciBBdXRo
b3JzLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i
c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+VGhpcyBpcyBEZWphLXZ1
IHRvIG1lLi4uLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RHJhZnQgPC9m
b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmRyYWZ0LWlldGYtY2NhbXAt
cnN2cC1yZXN0YXJ0LWV4dC0wNS50eHQNCmFjdHVhbGx5IGhhZCBhIHNlY3Rpb24gb24gbXVsdGlw
bGUgbm9kZSByZXN0YXJ0IGNhc2UgYW5kIHdhcyByZWplY3RlZCBieQ0KdGhlIFdHIGFzIGFkZHJl
c3NpbmcgbXVsdGlwbGUgbm9kZSByZXN0YXJ0IGNhc2UgaXMgTk9UIGEgZ29hbCAoc3VmZmVycw0K
ZnJvbSB0aGUgbGF3IG9mIGRpbWluaXNoaW5nIHJldHVybikuIEluIG90aGVyIHdvcmRzIHRoZSBm
b2xsb3dpbmcgc3RhdGVtZW50DQppbiB0aGUgSUQtIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7JnF1b3Q7W0dSLUVYVF0gYWxzbyBleHRlbmRzDQp0aGUg
SGVsbG8gbWVzc2FnZSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbiBhYm91dCA8L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7dGhlIGFiaWxpdHkgdG8gc3Vw
cG9ydCB0aGUgUmVjb3ZlcnlQYXRoDQptZXNzYWdlLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7VGhlIGV4YW1wbGVzIGFuZCBwcm9jZWR1cmVzDQpp
biBbR1ItRVhUXSBmb2N1cyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgYSA8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7c2luZ2xlIG5vZGUgcmVzdGFydCB3
aGVuIGFkamFjZW50DQpuZXR3b3JrIG5vZGVzIGFyZSBvcGVyYXRpdmUuIDwvZm9udD4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDtBbHRob3VnaCB0aGUgcHJvY2Vk
dXJlcyBhcmUNCmVxdWFsbHkgYXBwbGljYWJsZSB0byBtdWx0aS1ub2RlIHJlc3RhcnRzLCA8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7bm8gZGV0YWls
ZWQgZXhwbGFuYXRpb24gaXMgcHJvdmlkZWQuJnF1b3Q7DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJBcmlhbCI+aXMgbm90IGFjY3VyYXRlLiBQbGVhc2Ugc2VlIHNlY3Rpb24gNCBvbg0K
dGhlIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGUgW0dSLUVYVF0sIDwvZm9udD48YSBocmVmPSJodHRw
Oi8vd3d3LmZhcXMub3JnL2Z0cC9wdWIvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhaG1hbi1jY2Ft
cC1yc3ZwLXJlc3RhcnQtZXh0ZW5zaW9ucy0wMC50eHQiPjxmb250IHNpemU9MiBjb2xvcj1ibHVl
IGZhY2U9IkFyaWFsIj48dT5odHRwOi8vd3d3LmZhcXMub3JnL2Z0cC9wdWIvaW50ZXJuZXQtZHJh
ZnRzL2RyYWZ0LXJhaG1hbi1jY2FtcC1yc3ZwLXJlc3RhcnQtZXh0ZW5zaW9ucy0wMC50eHQ8L3U+
PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPi4NCjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzLi4uIFphZmFyIDwvZm9udD4NCjxicj48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxi
cj48Zm9udCBzaXplPTM+PHR0Pjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v
dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBw
cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh
dGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0
ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl
IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlz
IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs
IGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu
dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo
aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1l
c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0
aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk
IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvdHQ+
PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1
cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5l
ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3By
b3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4m
bmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp
ZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZu
YnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5k
Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZu
YnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlv
biZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55
Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZu
YnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7
Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i
c3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5i
c3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5i
c3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25v
dGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3Nh
Z2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMm
bmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu
ZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2Jl
ZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0m
bmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg==
--=_alternative 00109677482571EF_=--

--=_mixed 00109675482571EF_=
Content-Type: text/plain; name="draft-jian-ccamp-multinodes-rsvp-restart-00.txt"
Content-Disposition: attachment; filename="draft-jian-ccamp-multinodes-rsvp-restart-00.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                   JiangWeilian(ZTE Corporation)
                                             FengJun(ZTE Corporation)
Internet-Draft                               CuiYing(ZTE Corporation)
Expires: May 20, 2006                       KongYong(ZTE Corporation)
                                             LuoJian(ZTE Corporation)
                                                     =20
                                                  November 20,  2005     =20
                                              =20

                 Mechanism of multiple adjacent nodes  RSVP=20
                      graceful restart Simultaneously

                 draft-jian-ccamp-multinodes-rsvp-restart-00


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 5 of RFC3209, Section 9 of RFC3473.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on May 20, 2006.


Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.




Luojian              Expires: May 2006                      [Page 1]

Internet-Draft  draft-jian-ccamp-multinodes-rsvp-restart-00  Oct. 2005


Abstract

   Based on the RSVP graceful restart defined in the RFC3473, RFC3209,=20
   Node ID RSVP Hello:A Clarification Statement (draft-ietf-ccamp-rsvp
   -node-id-based-hello-02) and  the Extensions to GMPLS RSVP Graceful
   Restart (draft-ietf-ccamp-rsvp-restart-ext-05), this document puts=20
   forward extension to solve the problem for the restart node to
   actively inform RSVP graceful restart to the neighbor, and further
   provides the relevant mechanism to support recovery processing of
   RSVP graceful restart at simultaneous restart of multiple adjacent=20
   nodes.



Table of Contents

   1.  Conventions used in this document. . . . . . . . . . . . . .  3
   2.  Terms and abbreviation . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  . 3
   4.  Actively Informing Neighbor=20
       of RSVP GR Capability by Restarted Node . . . . . . . . . . . 4
   4.1 Adopting Multicast Address . . . . . . . . . . . . . . . . .  4
   4.2 Adopting Hot Backup . . . . . . . . . . . . . . . . . . . . . 5
   5.  RSVP GR Processing at Simultaneous Restart
       of Multiple Adjacent Nodes .  . . . . . . . . . . . .  . . .  5
   5.1 Multiple Adjacent Restart Nodes are Intermediate
       Nodes of the Tunnel . . . . . . . . . . . . . . . . . . . . . 5
   5.2 Multiple Adjacent Restart Nodes Contain
       Tunnel Tail Node  . . . . . . . . . . . . . . . . . . . . . . 7
   5.3 Multiple Adjacent Restart Nodes Contain
       Tunnel Head Node. . . .	. . . . . . . . .. . . . . .  . . .  7
   5.4 Multiple Adjacent Restart Nodes Contain=20
       All the Tunnel Nodes. . . . . . . . . . . . . . . . . . . . . 9
   6.  References  . . . . . . . . . . . . . . . . . .  . . . . . .  9
 =20





Luojian              Expires: May 2006                        [Page 2]

Internet-Draft  draft-jian-ccamp-multinodes-rsvp-restart-00  Oct. 2005



1 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in=20
   this document are to be interpreted as described in [RFC-2119].

2 Terms and abbreviation

   Suppose the reader is familiar with terms defined in [RFC3209],=20
   [RFC3473].

3 Overview

   In the RSVP Graceful Restart defined in Section 9 of RFC3473, the=20
   Hello mechanism defined by RFC3209 is extended to support GR
   (Graceful Restart) capability informing and fault detection between
   RSVP neighbors. It aims to define Resatrt=5FCap object for Hello=20
   extension to carry GR capability parameter and inform it to the=20
   neighbor through Hello  message interaction.

   The Hello mechanism defined by RFC3209 defines the message=20
   destination address and source address as the inter-neighbor=20
   interface IP address in turn. In draft-ietf-ccamp-rsvp-node-id-based
   -hello-02, the extension defines that the destination address and=20
   source address of Hello message supporting GR are TE RouterID of=20
   respective nodes.

   Then, the restart node is usually at a passive position. Only after=20
   it receives the RSVP GR Hello message from the neighbor, will it=20
   inform the neighbor of its GR capability b returning the ACK message.=20
   For restart of a single node, GR capability informing in the passive=20
   mode is also acceptable.

   If multiple adjacent nodes restart at the same time, however, these=20
   nodes cannot learn about the GR capability from each other. This=20
   document puts forward the solution of using the multicast address as
   destination address or adopting the hot backup technology to=20
   implement active informing of restarted node RSVP GR capability, and
   further provides the relevant mechanism to support recovery=20
   processing of RSVP GR at simultaneous restart of multiple adjacent=20
   nodes.




Luojian              Expires: May 2006                      [Page 3]

Internet-Draft  draft-jian-ccamp-multinodes-rsvp-restart-00  Oct. 2005


4 Actively Informing Neighbor of RSVP GR Capability by Restarted Node

4.1 Adopting Multicast Address

   After the node restarts and makes sure it supports RSVP GR Recovery,
   it can periodically send the GR HELLO message outward in the 1/2=20
   RecoveryTime through all the RSVP interfaces to inform its GR=20
   capability. Main field data composing the GR HELLO request message:

      The destination IP address is multicast address (IPv4: 224.0.0.2;
      IPv6: FF02:0:0:0:0:0:0:2).

      The source IP address is the local TE RouterID.

      The source instance value is the created value (the neighbors=20
      under different interfaces can be the same).

      The destination instance value is 0.

      The Restart time value of Restart=5FCap object is the local=20
      configuration value.

      The Recovery time of Restart=5FCap object is the local configuration
      value.

      The R digit value of Capability object is 1 (it indicates the node
      supports receiving of the RecoveryPath message).

      The T digit value of Capability object is 1 (it indicates the node
      supports sending of the RecoveryPath message).

      The S digit value of Capability object is 0 (it indicates the node
      does not support abstract refreshing message; for support, it can=20
      be set as 1).

      The Reserved digit value of Capability object is 0.
 =20
   When the neighbor receives the GR HELLO request message with this=20
   destination address as multicast address, it can first use the=20
   informed source RouterID as the neighbor RouterID and local RouterID
   to query if the corresponding HELLO instance exists:

      If the instance does not exist, it will create a corresponding=20
      instance, save the GR capability parameter informed by the peer,=20
      and confirms restart of the peer node based on the fact that the=20
      destination IP address is the multicast address. According to the=20
      informed GR capability parameter, it confirms that the peer is in
      the Recovery stage, replies the ACK message to the restart=20
      neighbor based on its GR capability, and then creates the=20
      corresponding Recovery Timer.


Luojian              Expires: May 2006                      [Page 4]

Internet-Draft  draft-jian-ccamp-multinodes-rsvp-restart-00  Oct. 2005


      If the instance exists, it will save the GR capability parameter
      informed by the peer, and reply the ACK message to the restart=20
      neighbor based on its GR capability.
=20
   After receiving the ACK reply message from the neighbor, the restart
   node can create the corresponding GR Hello instance in accordance=20
   with the information in the message. By now, the GR Hello relation=20
   between the restart node and neighbor node is reestablished.

   If the destination IP address of the GR HELLO request message=20
   received by the restart node from its neighbor is also the multicast
   address, it means that the neighbor node is also a restart node. In
   this case, it similarly creates a corresponding instance, saves the
   GR capability parameter informed by the peer, confirms that the peer
   node is restarted and in the Recovery stage, and creates the=20
   corresponding Recovery Timer.

   After 1/2RecoveryTime, the restart node must stop sending of the GR
   Hello message with the destination IP address as multicast address.=20
   In stead, it just implements GR Hello communication according to the
   created GR Hello instance.

4.2 Adopting Hot Backup

   If the node conducts hot backup of key data for the established GR
   HELLO instance, such as the neighbor RouterID, local RouterID, source
   instance value, destination instance value, outgoing interface and=20
   the next-hop address.

   Then, the restart node, after hot backup switching and restart, can
   get the hot backup GR HELLO instance data before restart, and=20
   actively constitute a GR Hello instance based on these data to send
   a new GR Hello message to inform the neighbor. Then, it=20
   reestablishes the GR HELLO relation with the neighbor node.

5 RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes

   Suppose Tunnel1 is established along with the LSR1-LSR2-LSR3-LSR4=20
   path. LSR1, LSR2, LSR3 and LSR4 all support RSVP GR, and all the=20
   nodes support sending and receiving of the Recovery Path message.

5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel

   Suppose LSR2 and LSR3 start at the same time.

   LSR1 and LSR4 enter the Restart stage, and they send the GR Hello=20
   message to LSR2 and LSR3 in turn.



Luojian              Expires: May 2006                      [Page 5]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005


   After the LSR2 and LSR3 restart, they will enter the GR Recovery
   stage according to the configuration. With the method described in
   Section 4, a GR Hello relation can be set up between LSR2 and LSR3,
   and they can learn that the peer party is in the GR Recovery stage.

   At the same time, LSR1 and LSR4 will send the GR Hello request
   message to LSR2 and LSR3 in turn, and LSR2 and LSR3 will create
   the corresponding GR HELLO instance, respond to the request messages
   from LSR1 and LSR4, inform the peer party of support to GR, and then
   enter the Recovery stage together.

   After that, LSR1 will send the Path message with Recovery Label=20
   object to LSR2. (if sending and receiving of RecoveryPath message are
   supported, LSR4 will also send the RecoveryPath message to LSR3).
  =20
   After receiving the Path message with Recovery Label object, LSR2=20
   will check if the corresponding PSB exists. Suppose it cannot be=20
   found, but the corresponding entry is found from the MPLS forwarding=20
   table, LSR2 will create the corresponding PSB.

   However, because the GR Hello relation has been established between
   LSR2 and LSR3, and they learn that the peer part is in the GR=20
   Recovery stage, then LSR2 can send the Path message carrying Recovery
   Label object to LSR3. Here, the outgoing label and outgoing interface
   are obtained by query of the forwarding table, and the next-hop=20
   address can be obtained through the ERO object of Path message sent=20
   upstream.

   After receiving the Path message carrying Recovery Label object from
   the restart node LSR2, LSR3 will find out if the corresponding PSB
   exists according to the received Path message. Suppose it is not=20
   found, but the corresponding entry is found from the MPLS forwarding
   table. Then, LSR3 creates the corresponding PSB, constitutes the=20
   Path message containing Suggested Label object and sends it to the
   downstream LSR4.

   After receiving the Path refreshing message containing Suggested=20
   Label object from the restart node LSR3, LSR4 resolves the incoming
   label of LSP for recovery through the Suggested=5FLabel object in
   the Path message. Then, it matches the corresponding RSB, refreshes
   (clears) the stale flag for the corresponding forwarding table=20
   entry, and triggers the corresponding Resv message to send it to=20
   LSR3.

   LSR3 receives the Resv message from LSR4, creates RSB and associates
   the corresponding PSB. Now, both the incoming label and outgoing
   label are refreshed. LSR3 clears the stale flag for the corresponding
   forwarding entry and sends the Resv message to LSR2.


Luojian              Expires: May 2006                      [Page 6]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005


   LSR2 receives the Resv message from LSR3, creates RSB and associates
   the corresponding PSB. Now, both the incoming label and outgoing=20
   label are refreshed. LSR2 clears the stale flag for the corresponding
   forwarding entry and sends the Resv message to LSR1.

   LSR1 receives the Resv message, refreshes RSB, and clears the stale=20
   flag of relevant protocol state. Now, Tunnel1 is completely=20
   recovered.


5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node

   Suppose LSR2, LSR3 and LSR4 start at the same time.

   LSR1 enters the Restart stage, and it sends the GR Hello message to
   LSR2.

   After LSR2, LSR3 and LSR4 all restart, they will enter the GR=20
   Recovery stage according to the configuration. With the method=20
   described in Section 4, a GR Hello relation can be set up between=20
   LSR2, LSR3 and LSR4, and they can learn that the peer party is in=20
   the GR Recovery stage.

   At the same time, LSR1 will send the GR Hello request message to=20
   LSR2, and LSR2 will create the corresponding GR HELLO instance,=20
   respond to the request messages from LSR1, inform the peer party of
   support to GR, and then enter the Recovery stage together.

   After that, LSR1 will send the Path message with Recovery Label=20
   object to LSR2.

   The following handing is the same as the description in  Section
   5.1. The Path message is sent to LSR3. After handing by LSR3, the=20
   Path carrying Recovery Label object is sent to LSR4, instead of the
   Path message carrying Suggested Label object.

   Then, LSR4 sends the Resv message upstream, and each hop is=20
   recovered in turn along with the upstream path till LSR1. Finally,=20
   Tunnel1 is completely recovered.


5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node

   Suppose LSR1, LSR2 and LSR3 start at the same time.
  =20
   LSR4 enters the Restart stage, and it sends the GR Hello message to
   LSR3.

   After LSR1, LSR2 and LSR3 all restart, they will enter the GR=20
   Recovery stage according to the configuration. With the method=20
   described in Section 4, a GR Hello relation can be set up between
   LSR1, LSR2 and LSR3, and they can learn that the peer party is in=20
   the GR Recovery stage.

Luojian              Expires: May 2006                      [Page 7]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005


   At the same time, LSR4 will send the GR Hello request message to
   LSR3, and LSR3 will create the corresponding GR HELLO instance,=20
   respond to the request messages from LSR4, inform the peer party of=20
   support to GR, and then enter the Recovery stage together.

   After that, only LSR4 will send the Recovery Path message to LSR3.
   (therefore, we suppose all the nodes support sending and receiving
   of the Recovery Path message.)

   When receiving the RecoveryPath message from the assistant node=20
   LSR4, LSR3 will find out if the corresponding PSB exists according
   to the received PATH message. Suppose it is not found, but the
   corresponding entry is found from the MPLS forwarding table. Then,=20
   LSR3 creates the corresponding PSB (possibly the original Path=20
   message should have the RRO object, which can be used to get the=20
   previous-hop address and recover the ERO containing the previous-hop
   address), and constitutes the Path message containing Suggested Label
   object to send it to the downstream LSR4 and wait for the Resv=20
   message from LSR4.

   After receiving the Path refreshing message containing Suggested
   Label object from the restart node LSR3, LSR4 resolves the incoming
   label of LSP for recovery through the Suggested=5FLabel object in the=20
   Path message. Then, it matches the corresponding RSB, refreshes=20
   (clears) the stale mark for the corresponding forwarding table entry,=20
   and triggers the corresponding Resv message to send it to LSR3.

   After receiving the Resv message from LSR4, LSR3 creates the=20
   corresponding RSB, and refreshes (clears) the stale flag for the=20
   corresponding forwarding table entry. Then, LSR3 will send the=20
   Recovery Path message to LSR2.

   The same as handling of LSR3, LSR2, after receiving the RecoveryPath
   message from LSR3, will create the corresponding PSB, constitute the=20
   Path message containing Suggested Label object to send it to the=20
   downstream LSR3 and wait for the Resv message from LSR3.
=20
   After receiving the Resv message from LSR3, LSR2 creates the=20
   corresponding RSB, and refreshes (clears) the stale flag for the
   corresponding forwarding table entry. Then, LSR2 will send the=20
   Recovery Path message to LSR1.

   Similarly, LSR1 creates the corresponding PSB and RSB, and refreshes
   (clears) the stale flag for the corresponding forwarding table entry.
   Now, Tunnel1 is completely recovered.


Luojian              Expires: May 2006                        [Page 8]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005


5.4 Multiple Adjacent Restart Nodes Contain All the Tunnel Nodes

   Suppose LSR1, LSR2, LSR3 and LSR4 start at the same time.
   After LSR1, LSR2, LSR3 and LSR4 all restart, they will enter the GR
   Recovery stage according to the configuration. With the method=20
   described in Section 4, a GR Hello relation can be set up between=20
   LSR1, LSR2, LSR3 and LSR4, and they can learn that the peer party is
   in the GR Recovery stage.

   However, none of the four LSRs has the Tunnel1 protocol state data=20
   before restart, so they cannot constitute any recovery Path message=20
   to be sent to the neighbor. In this case, Tunnel1 can only wait for
   reestablishment of LSR1 after the GR Recovery stage ends.


6 References

   [RFC3209]   Awduche, D., et al., "Extensions to RSVP for LSP=20
               Tunnels", December 2001.=20

   [RFC3473]   Berger, L., et al., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Resource ReserVation=20
               Protocol-Traffic Engineering (RSVP-TE) Extensions",=20
               January 2003.

   [RFC1112]   Deering, S., "Host Extensions for IP Multicasting",=20
               Stanford University, August 1989.

   [RFC2375]   Hinden, R., et al., "IPv6 Multicast Address Assignments",=20
               July 1998.

   IANA       =A1=B0INTERNET MULTICAST ADDRESSES=A1=B1, September 2005

   [draft-ietf-ccamp-rsvp-node-id-based-hello-02]
               Zafar Ali, et al.,"Node ID based RSVP Hello: A=20
               Clarification Statement", September 2005.

   [draft-ietf-ccamp-rsvp-restart-ext-05] =20
               Satyanarayana, et al., "Extension to GMPLS RSVP Graceful
               Restart", September 2005.



Luojian              Expires: May 2006                        [Page 9]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005

   =20
Authors Addresses=20

   JiangWeilian=20
  =20
   No.68 Zijinghua Road, Yuhuatai District
   Nanjing, China=20
   Phone: [phone]=20
   Email: [e-mail]

 =20
   FengJun

   No.68 Zijinghua Road, Yuhuatai District
   Nanjing, China=20
   Phone: [phone]=20
   Email: [e-mail]


   CuiYing

   No.68 Zijinghua Road, Yuhuatai District
   Nanjing, China=20
   Phone: [phone]=20
   Email: [e-mail]

  =20
   KongYong
   No.68 Zijinghua Road, Yuhuatai District
   Nanjing, China=20
   Phone: [phone]=20
   Email: [e-mail]

=20
   LuoJian
=20
   No.68 Zijinghua Road, Yuhuatai District
   Nanjing, China=20
   Phone: [phone]=20
   Email: [e-mail]
  =20
   Comments are solicited and should be addressed to the working=20
   group's mailing list at [e-mail] and/or the author(s).


Luojian              Expires: May 2006                       [Page 10]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005


Intellectual Property Statement=20
   =20
   The IETF takes no position regarding the validity or scope of any=20
   intellectual property or other rights that might be claimed to=20
   pertain to the implementation or use of the technology described in=20
   this document or the extent to which any license under such rights=20
   might or might not be available; neither does it represent that it=20
   has made any effort to identify any such rights.  Information on the=20
   IETF's procedures with respect to rights in standards-track and=20
   standards-related documentation can be found in BCP-11.  Copies of=20
   claims of rights made available for publication and any assurances of=20
   licenses to be made available, or the result of an attempt made to=20
   obtain a general license or permission for the use of such=20
   proprietary rights by implementers or users of this specification can=20
   be obtained from the IETF Secretariat.=20
       =20
   The IETF invites any interested party to bring to its attention any=20
   copyrights, patents or patent applications, or other proprietary=20
   rights, which may cover technology that may be required to practice=20
   this standard.  Please address the information to the IETF Executive=20
   Director.=20


Disclaimer of Validity
  =20
   This document and the information contained herein are provided on an=20
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=20
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   =20
Full Copyright Statement=20
   =20
   Copyright (C) The Internet Society (2005).=20

   This document is subject to the rights, licenses and restrictions=20
   contained in BCP 78, and except as set forth therein, the authors=20
   retain all their rights.=20


Acknowledgments=20
   =20
   The authors would like to thank XuZhijun, DuKe, ZhuXinhua,=20
   ChenJianye and all the other people who have contributed to this=20
   draft, and also would like to thank all the future participants for
   their  comments and  suggestions.=20





Luojian              Expires: May 2006                      [Page 11]

Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005




--=_mixed 00109675482571EF_=--



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Sep 2006 12:43:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DBE8.F1529B3A"
Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
Date: Tue, 19 Sep 2006 13:45:47 +0100
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
Thread-Index: AcajzYu3Wna7e+MHRe2xxdCgls5b7A4GVrqQ
From: "Olufemi Komolafe" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "ccamp" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DBE8.F1529B3A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

While reading this draft it occurred to me that perhaps it might be more
useful to approach this topic from the perspective of "What can go wrong
during graceful restart, what are the consequences and how can it be
fixed?" rather than focusing on the narrower topic of multiple
simultaneous nodal faults.

=20

For example, Scenario 1 in the draft may be interpreted as "What should
happen if a (non-ingress) restarting node fails to get a RecoveryPath
message from its downstream neighbour?", Scenario 2 is "What should
happen if a (non-ingress) restarting node fails to get a Path message
from its upstream neighbour?" and so on.  Whether each of these
scenarios arises due to multiple simultaneous nodal faults (as in the
draft) or any other reason (e.g. a subsequent control channel failure,
restarting node being inundated with messages etc.) is, in my opinion,
secondary.  I think the key thing is to identify the potential problems
and suggest appropriate remedial actions, where the authors think
existing documentation is insufficient, rather than focusing on 5
different permutations of multiple node graceful restart.  =20

=20

Regards,

Femi

=20

=20

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Zafar Ali (zali)
Sent: 10 July 2006 04:04
To: [e-mail]; [e-mail]
Cc: ccamp
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,=20

=20

Dear Authors,=20

=20

This is Deja-vu to me....=20

=20

Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on
multiple node restart case and was rejected by the WG as addressing
multiple node restart case is NOT a goal (suffers from the law of
diminishing return). In other words the following statement in the ID-=20

=20

   "[GR-EXT] also extends the Hello message to exchange information
about=20

   the ability to support the RecoveryPath message.=20

   The examples and procedures in [GR-EXT] focus on the description of a


   single node restart when adjacent network nodes are operative.=20

   Although the procedures are equally applicable to multi-node
restarts,=20

   no detailed explanation is provided."=20

=20

is not accurate. Please see section 4 on the earlier version of the
[GR-EXT],
http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-rest
art-extensions-00.txt
<http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-res
tart-extensions-00.txt> .=20

=20

Thanks

=20

Regards... Zafar=20

=20


------_=_NextPart_001_01C6DBE8.F1529B3A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>While reading this draft it occurred to me that perhaps it might =
be
more useful to approach this topic from the perspective of &#8220;What =
can go
wrong during graceful restart, what are the consequences and how can it =
be
fixed?&#8221; rather than focusing on the narrower topic of multiple
simultaneous nodal faults.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>For example, Scenario 1 in the draft may be interpreted as =
&#8220;What
should happen if a (non-ingress) restarting node fails to get a =
RecoveryPath message
from its downstream neighbour?&#8221;, Scenario 2 is &#8220;What should =
happen
if a (non-ingress) restarting node fails to get a Path message from its
upstream neighbour?&#8221; and so on.&nbsp; Whether each of these =
scenarios arises
due to multiple simultaneous nodal faults (as in the draft) or any other =
reason
(e.g. a subsequent control channel failure, restarting node being =
inundated
with messages etc.) is, in my opinion, secondary. &nbsp;I think the key =
thing is
to identify the potential problems and suggest appropriate remedial =
actions,
where the authors think existing documentation is insufficient, rather =
than
focusing on 5 different permutations of multiple node graceful =
restart.&nbsp; &nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Femi<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Zafar Ali (zali)<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 10 July 2006 =
04:04<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail];
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> ccamp<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comments on
draft-li-ccamp-multinodes-gr-proc-00.txt, </span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dear Authors, </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is Deja-vu to me.... =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Draft </span></font><span =
lang=3DEN-US>draft-ietf-ccamp-rsvp-restart-ext-05.txt
actually had a section on multiple node restart case and was rejected by =
the WG
as addressing multiple node restart case is&nbsp;NOT a goal (suffers =
from the
law of diminishing return). In other words the following statement in =
the <st1:State
w:st=3D"on"><st1:place w:st=3D"on">ID-</st1:place></st1:State> =
</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; &quot;[GR-EXT] also extends the Hello =
message
to exchange information about </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; the ability to support the RecoveryPath
message. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; The examples and procedures in [GR-EXT] =
focus
on the description of a </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; single node restart when adjacent =
network nodes
are operative. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; Although the procedures are equally =
applicable
to multi-node restarts, </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; no detailed explanation is =
provided.&quot; </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>is not accurate. Please see section 4 on the earlier =
version
of the [GR-EXT], </span></font><a
href=3D"http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rs=
vp-restart-extensions-00.txt"><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>http://www.faqs.org/ftp/pub/=
internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt</span><=
/font></a><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Thanks</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Regards... Zafar </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6DBE8.F1529B3A--



Envelope-to: [e-mail]
Delivery-date: Sun, 17 Sep 2006 09:53:39 +0000
Message-ID: <099001c6da3f$19350de0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>, <[e-mail]>
Subject: Re: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling
Date: Sun, 17 Sep 2006 10:49:33 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Vijay,

> What is the rationale behind defining a new C-Type ( C-Type = 2,
> suggested value, TBA by IANA) for the PROTECTION Object in
> the e2e draft instead of extending C-Type = 1 defined in rfc3473?

If you are familiar with the way RSVP has been developed over the years you 
will notice that this is standard practice.

Consider the Session_Attribute object in RFC 3209. You will see two 
different C-Types here according to the content of the object.

Perhaps a better example is the RSVP Hop object. This appears in RFC 2205 
with C-Types 1 and 2 (for different uses) and is extended in RFC 3473 with 
two new C-Types.

The C-Type is used to distinguish sub-types of the same object. This is, of 
course, useful, in normal implementation because it means that we don't have 
to make assumptions about the object's contents from parsing other fields 
(like the length). It is particulalry useful when a new variant of an object 
is introduced because it enables backward compatibility problems to be 
detected - a legacy implementation that does not support the new C-Type will 
reject the message (see RFC 2205) and the message sender can then take 
action to avoid the problem.

In the case of draft-ietf-ccamp-gmpls-recovery-e2e-signaling, you'll notice 
that although the format of the first 8 bytes of the C-Type2 Protection 
object matches the C-Type1 Protection object in RFC 3473 with the adoption 
of some of the reserved bits, an extra 32 bit reserved field is added to the 
end of the object. (As indicated in 
draft-ietf-ccamp-gmpls-recovery-e2e-signaling, these 32 bits are defined in 
draft-ietf-ccamp-gmpls-segment-recovery.) So the processing for the two 
C-Types is different and it is useful to be able to distinction them through 
a different code point.

> Should we consider C-Type = 1 as obsolete?

Why?
You must interoperate with 3473 implementations (always assuming interop is 
on your agenda) and any implementation not wanting e2e or segment protection 
can continue to use C-Type 1.

Adrian





Envelope-to: [e-mail]
Delivery-date: Sun, 17 Sep 2006 09:49:31 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], "Pandian, Vijay" <[e-mail]>
Subject: Re: RFC3630 - Local and Remote Interface IP address
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 17 Sep 2006 11:48:55 +0200
Content-Type: text/plain; charset="US-ASCII"

adrian 

point is that one can have two different readings of these sentences 

either one assigns multiple IP addresses and configures a specific map of 
these addresses to components (e.g. sub-interfaces)
or it is meant just to assign multiple IP addresses to an interface 
independently of this segmentation

however, there is no bundling concept in this ref. or equivalently the 
bundling RFC maps a single (composed) TE link to a TE link (with specific 
aggregation rules when it comes to TE attributes) that is RFC4201 uses a 
single value for the link local/remote address/interface associated to the 
bundle

thanks,
- d.






"Adrian Farrel" <[e-mail]>
17/09/2006 11:31
Please respond to "Adrian Farrel"
 
        To:     "Pandian, Vijay" <[e-mail]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>, <[e-mail]>, <[e-mail]>
        Subject:        Re: RFC3630 - Local and Remote Interface IP 
address


Hi Vijay,

OSPF-TE implementers may wish to disagree with me on this, but I think 
Dimitri's definitive statement does not cover the basic reasoning for this 

feature.

While it is true that one can use multiple link addresses to identify 
multiple component links, I think that the multiplicity of link addresses 
is 
provided in this RFC so that a single TE link may support multiple 
interfaces. This is an implementation choice, and may be advantageous in 
some cases.

If the multiple link addresses are used to identify multiple component 
links, then I would expect a 1:1 correspondence between the link ends. If 
the addresses are used to identify different interfaces to the same link 
then I would not necessarily expect a 1:1 correspondence.

In answer to your most recent questions:

> Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link."

And so it does.
It describes a single TE link.
A link bundle is still a single TE link, but it is made up of multiple 
component links that are not identified as TE links in their own right.

> Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV
> specifies the IP address(es) of the interface corresponding to this 
link."
>
> Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV
> specifies the IP address(es) of the neighbor's interface corresponding 
to
> this link."

As above

> Doesn't this mean the Local and Remote Interface IP Address sub-TLV
> corresponds to just ONE TE-Link?

Yes, it does.

> There is no mention of "components" anywhere in this document. Even in
> rfc4201, it is not clear that when multiple (component) TE-Links are
> aggregated as a single numbered bundled link, there can be more than one
> Interface IP address used for Local and Remote Interface IP Address.
>
> Could you please provide a reference where this is clarified as the mean 

> for
> advertising multiple components at once.

I don't think you will find such a reference.
What is clear is that an implementation MAY assign multiple interface IP 
addresses.
Therefore, there is nothing to stop an implementation using the component 
link identifiers as the set of interface IP addresses.
Since each component link is in just one bundle, the use of a component 
link 
identifier uniquely identifies the bundle.
This mechanism of advertising is, therefore, a clever way of advertising 
bundle membership information to the neighbor.

If you want a more definitive statement of how this can work, you should 
probably develop an Applicability Statement I-D.

Regards,
Adrian

> Thanks and best regards,
>
> Vijay
>
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 06, 2006 1:57 AM
> To: Pandian, Vijay
> Subject: Re: RFC3630 - Local and Remote Interface IP address
>
>
> hi vijay - this was meant for advertizing multiple components at once
>
>
>
>
> "Pandian, Vijay" <[e-mail]>
> Sent by: [e-mail]
> 06/07/2006 02:56
>
>        To:     [e-mail]
>        cc:     [e-mail], [e-mail]
>        Subject:        RFC3630 - Local and Remote Interface IP address
>
>
> Section 2.5.3 indicates that there can be more than one Local Interface 
IP
> address assigned to a (numbered) TE-Link. Similarly, section 2.5.4
> indicates that there can be more than one Remote Interface IP Address
> assigned to a (numbered) TE-Link.
>
> Is there any requirement that the number of Local Interface IP address
> assigned to a given TE-link match the number of Remote Interface IP
> address.
>
> Specifically, can a TE-Link have just one Local Interface IP address but
> multiple Remote Interface IP Address or vice-versa?
>
> Best regards,
>
> Vijay
>
>
>
> 







Envelope-to: [e-mail]
Delivery-date: Sun, 17 Sep 2006 09:34:20 +0000
Message-ID: <097c01c6da3c$1ab832d0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: RFC3630 - Local and Remote Interface IP address
Date: Sun, 17 Sep 2006 10:31:31 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Vijay,

OSPF-TE implementers may wish to disagree with me on this, but I think 
Dimitri's definitive statement does not cover the basic reasoning for this 
feature.

While it is true that one can use multiple link addresses to identify 
multiple component links, I think that the multiplicity of link addresses is 
provided in this RFC so that a single TE link may support multiple 
interfaces. This is an implementation choice, and may be advantageous in 
some cases.

If the multiple link addresses are used to identify multiple component 
links, then I would expect a 1:1 correspondence between the link ends. If 
the addresses are used to identify different interfaces to the same link 
then I would not necessarily expect a 1:1 correspondence.

In answer to your most recent questions:

> Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link."

And so it does.
It describes a single TE link.
A link bundle is still a single TE link, but it is made up of multiple 
component links that are not identified as TE links in their own right.

> Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV
> specifies the IP address(es) of the interface corresponding to this link."
>
> Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV
> specifies the IP address(es) of the neighbor's interface corresponding to
> this link."

As above

> Doesn't this mean the Local and Remote Interface IP Address sub-TLV
> corresponds to just ONE TE-Link?

Yes, it does.

> There is no mention of "components" anywhere in this document. Even in
> rfc4201, it is not clear that when multiple (component) TE-Links are
> aggregated as a single numbered bundled link, there can be more than one
> Interface IP address used for Local and Remote Interface IP Address.
>
> Could you please provide a reference where this is clarified as the mean 
> for
> advertising multiple components at once.

I don't think you will find such a reference.
What is clear is that an implementation MAY assign multiple interface IP 
addresses.
Therefore, there is nothing to stop an implementation using the component 
link identifiers as the set of interface IP addresses.
Since each component link is in just one bundle, the use of a component link 
identifier uniquely identifies the bundle.
This mechanism of advertising is, therefore, a clever way of advertising 
bundle membership information to the neighbor.

If you want a more definitive statement of how this can work, you should 
probably develop an Applicability Statement I-D.

Regards,
Adrian

> Thanks and best regards,
>
> Vijay
>
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 06, 2006 1:57 AM
> To: Pandian, Vijay
> Subject: Re: RFC3630 - Local and Remote Interface IP address
>
>
> hi vijay - this was meant for advertizing multiple components at once
>
>
>
>
> "Pandian, Vijay" <[e-mail]>
> Sent by: [e-mail]
> 06/07/2006 02:56
>
>        To:     [e-mail]
>        cc:     [e-mail], [e-mail]
>        Subject:        RFC3630 - Local and Remote Interface IP address
>
>
> Section 2.5.3 indicates that there can be more than one Local Interface IP
> address assigned to a (numbered) TE-Link. Similarly, section 2.5.4
> indicates that there can be more than one Remote Interface IP Address
> assigned to a (numbered) TE-Link.
>
> Is there any requirement that the number of Local Interface IP address
> assigned to a given TE-link match the number of Remote Interface IP
> address.
>
> Specifically, can a TE-Link have just one Local Interface IP address but
> multiple Remote Interface IP Address or vice-versa?
>
> Best regards,
>
> Vijay
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 15 Sep 2006 19:50:31 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-06.txt 
Message-Id: <[e-mail]>
Date: Fri, 15 Sep 2006 15:50:02 -0400

--NextPart

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		: GMPLS - Communication of Alarm Information
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-alarm-spec-06.txt
	Pages		: 20
	Date		: 2006-9-15
	
This document describes an extension to Generalized MPLS (Multi-
Protocol Label Switching) signaling to support communication of alarm
information.  GMPLS signaling already supports the control of alarm
reporting, but not the communication of alarm information.  This
document presents both a functional description and GMPLS-RSVP
specifics of such an extension.  This document also proposes
modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473 "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions" through the addition of new,
optional protocol elements. It does not change, and is fully backward
compatible with the procedures specified in RFC 3473.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-alarm-spec-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-alarm-spec-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 15 Sep 2006 18:57:04 +0000
From: "Jim Jones" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>
Cc: <[e-mail]>, "'Brungard, Deborah A, ALABS'" <[e-mail]>, "'Ross Callon'" <[e-mail]>, "'Bill Fenner'" <[e-mail]>
Subject: RE: New CCAMP RFC of Interest to OIF
Date: Fri, 15 Sep 2006 13:55:54 -0500
Message-ID: <003901c6d8f8$94dabcd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcbY7YEDw64Nfe3gSs2k719pH0g66gACt7wQ

Dear Adrian and Deborah,

Thank you for the update. I will make the membership aware of this new RFC.

Best Regards,
Jim Jones
OIF Technical Committee Chair

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Friday, September 15, 2006 12:33 PM
To: Jim Jones
Cc: [e-mail]; Brungard, Deborah A, ALABS; Ross Callon; Bill Fenner
Subject: New CCAMP RFC of Interest to OIF

Dear Jim,

The CCAMP working group of the IETF is pleased to inform you of the
publication of RFC 4606: Generalized Multi-Protocol Label Switching
(GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control.

The Abstract to this RFC reads as follows:

   This document is a companion to the Generalized Multi-protocol Label
   Switching (GMPLS) signaling.  It defines the Synchronous Optical
   Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-
   specific information needed when GMPLS signaling is used.

The RFC can be downloaded free of charge from
http://www.ietf.org/rfc/rfc4606.txt

RFC 4606 obsoletes RFC 3946 and addresses a minor clarification arising from
a question raised by the OIF as a result of interworking tests.

Further information about the work of the CCAMP working group can be found
at our charter page:
http://www.ietf.org/html.charters/ccamp-charter.html

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP Working Group Co-Chairs





Envelope-to: [e-mail]
Delivery-date: Fri, 15 Sep 2006 17:42:29 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: Greg Jones <[e-mail]>
Cc: Stephen Trowbridge <[e-mail]>, Kam Lam <[e-mail]>, CCAMP Mailing List <[e-mail]>, Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>, Scott Bradner <[e-mail]>, Deborah Brungard <[e-mail]>, Adrian Farrel <[e-mail]>, Adrian Farrel <[e-mail]>
From: Adrian Farrel (IETF CCAMP WG) <[e-mail]>
Subject: New Liaison Statement, "New RFC on GMPLS Extensions for  SONET/SDH" 
Reply-To: Adrian Farrel <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 15 Sep 2006 13:42:17 -0400

Title: New RFC on GMPLS Extensions for SONET/SDH
Submission Date: 2006-09-15
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=264 

From: Adrian Farrel(IETF CCAMP WG) <[e-mail]>
To: ITU-T SG15(Greg Jones <[e-mail]>)
Cc: Stephen Trowbridge <[e-mail]>
Kam Lam <[e-mail]>
CCAMP Mailing List <[e-mail]>
Ross Callon <[e-mail]>
Bill Fenner <[e-mail]>
Scott Bradner <[e-mail]>
Deborah Brungard <[e-mail]>
Reponse Contact: Adrian Farrel <[e-mail]>
Technical Contact: Adrian Farrel <[e-mail]>
Purpose: For information 
Body: The CCAMP working group of the IETF is pleased to inform you of the 
publication of RFC 4606: Generalized Multi-Protocol Label Switching
(GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control.

The Abstract to this RFC reads as follows:

   This document is a companion to the Generalized Multi-protocol Label
   Switching (GMPLS) signaling.  It defines the Synchronous Optical
   Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-
   specific information needed when GMPLS signaling is used.

The RFC can be downloaded free of charge from http://www.ietf.org/rfc/rfc4606.txt

RFC 4606 obsoletes RFC 3946 and addresses a minor clarification.

Further information about the work of the CCAMP working group can be
found at our charter page http://www.ietf.org/html.charters/ccamp-charter.html

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP Working Group Co-Chairs
Attachment(s):
No document has been attached





Envelope-to: [e-mail]
Delivery-date: Fri, 15 Sep 2006 17:36:49 +0000
Message-ID: <081c01c6d8ed$5c273540$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jim Jones" <[e-mail]>
Cc: <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: New CCAMP RFC of Interest to OIF
Date: Fri, 15 Sep 2006 18:33:15 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Dear Jim,

The CCAMP working group of the IETF is pleased to inform you of the 
publication of RFC 4606: Generalized Multi-Protocol Label Switching
(GMPLS) Extensions for Synchronous Optical Network (SONET) 
and Synchronous Digital Hierarchy (SDH) Control.

The Abstract to this RFC reads as follows:

   This document is a companion to the Generalized Multi-protocol Label
   Switching (GMPLS) signaling.  It defines the Synchronous Optical
   Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-
   specific information needed when GMPLS signaling is used.

The RFC can be downloaded free of charge from 
http://www.ietf.org/rfc/rfc4606.txt

RFC 4606 obsoletes RFC 3946 and addresses a minor clarification arising
from a question raised by the OIF as a result of interworking tests.

Further information about the work of the CCAMP working group can be
found at our charter page:
http://www.ietf.org/html.charters/ccamp-charter.html

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP Working Group Co-Chairs




Envelope-to: [e-mail]
Delivery-date: Fri, 15 Sep 2006 15:11:26 +0000
Sensitivity: 
Subject: Re: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt
To: "Adrian Farrel" <[e-mail]>
Cc: "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Fri, 15 Sep 2006 17:09:14 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,
        I'd like to thank you for having done this summary.

As an author of the ID I agree with your points.

We'll review the ID.

Regards

Diego



"Adrian Farrel" <[e-mail]>@ops.ietf.org on 15/09/2006 13.52.30

Please respond to "Adrian Farrel" <[e-mail]>

Sent by:    [e-mail]


To:    <[e-mail]>
cc:

Subject:    Attempting consensus on
       draft-caviglia-ccamp-pc-and-sc-reqs-03.txt

Hi,

We had a lively debate, and I promised to try to summarise the points to
see
if we have some form of consensus.

draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where
the authors say it is desirable to be able to transfer control of an LSP
between the management plane and a GMPLS control plane. They support this
claim with various scenarios. They then develop a series of requirements on
the process. The intention is to specify a process and develop any
necessary
protocol extensions.

Re-reading the thread, I think I see the following points:

1. General agreement that transfer of control from the management plane to
the control plane is a realistic scenario as a GMPLS control plane is
introduced into an existing network where LSPs have been established using
the management plane.

2. Some disagreement about whether point 1 needs to be performed
dynamically, but nevertheless agreement that some operators may wish to
make
the transfer hitlessly (i.e. without a maintenance period) and in a network
without sufficient spare capacity to establish a parallel LSP.

3. Considerable disagreement about some of the scenarios (documented and
raised on the mailing list) for the transfer of control from the control
plane to the management plane.

4. Some understanding that if transfer from the management plane to the
control plane is supported, there will be a desire to back-out the process,
for example if the operator is not happy with the result.

5. Some debate over whether either of the transfers (but particularly the
transfer from control plane to management plane) would result in any
extensions to the protocols.

6. Concern that handling failure events, where control of the LSP ends up
in
some mixed mode, could be very messy.


My conclusions, therefore, are:

A. There is consensus to work on transfer from the management plane to the
control plane.

B. There is enough interest to justify work on the transfer from the
control
plane to the management plane, but this should be scoped as a back-out
procedure.

C. The requirements should initially state the functional requirements and
should not assume that changes to the protocols are necessary. That is, if
the requirements draft can be answered with an applicability statement,
that
would be good all round. Later section of the draft can state current
protocol behavior, and point out any gaps that need to be filled.

D. The requirements draft must cover the requirements for failure cases in
good detail


We should encourage the authors to revise their draft along these lines at
which time the working group may be more likely to find itself in full
consensus.

Thanks,
Adrian











Envelope-to: [e-mail]
Delivery-date: Fri, 15 Sep 2006 14:53:34 +0000
Message-ID: <07b901c6d8d6$62cb9d30$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt
Date: Fri, 15 Sep 2006 12:52:30 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We had a lively debate, and I promised to try to summarise the points to see
if we have some form of consensus.

draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where
the authors say it is desirable to be able to transfer control of an LSP
between the management plane and a GMPLS control plane. They support this
claim with various scenarios. They then develop a series of requirements on
the process. The intention is to specify a process and develop any necessary
protocol extensions.

Re-reading the thread, I think I see the following points:

1. General agreement that transfer of control from the management plane to
the control plane is a realistic scenario as a GMPLS control plane is
introduced into an existing network where LSPs have been established using
the management plane.

2. Some disagreement about whether point 1 needs to be performed
dynamically, but nevertheless agreement that some operators may wish to make
the transfer hitlessly (i.e. without a maintenance period) and in a network
without sufficient spare capacity to establish a parallel LSP.

3. Considerable disagreement about some of the scenarios (documented and
raised on the mailing list) for the transfer of control from the control
plane to the management plane.

4. Some understanding that if transfer from the management plane to the
control plane is supported, there will be a desire to back-out the process,
for example if the operator is not happy with the result.

5. Some debate over whether either of the transfers (but particularly the
transfer from control plane to management plane) would result in any
extensions to the protocols.

6. Concern that handling failure events, where control of the LSP ends up in
some mixed mode, could be very messy.


My conclusions, therefore, are:

A. There is consensus to work on transfer from the management plane to the
control plane.

B. There is enough interest to justify work on the transfer from the control
plane to the management plane, but this should be scoped as a back-out
procedure.

C. The requirements should initially state the functional requirements and
should not assume that changes to the protocols are necessary. That is, if
the requirements draft can be answered with an applicability statement, that
would be good all round. Later section of the draft can state current
protocol behavior, and point out any gaps that need to be filled.

D. The requirements draft must cover the requirements for failure cases in
good detail


We should encourage the authors to revise their draft along these lines at
which time the working group may be more likely to find itself in full
consensus.

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Thu, 14 Sep 2006 16:24:36 +0000
To: Greg Jones <[e-mail]>
Cc: IESG <[e-mail]>, IAB <[e-mail]>, Steve Trowbridge <[e-mail]>, Malcolm Betts <[e-mail]>, Yoichi Maeda <[e-mail]>, Ghani Abbas <[e-mail]>, Houlin Zhao <[e-mail]>, CCAMP mailing list <[e-mail]>, MPLS mailing list <[e-mail]>, PWE3 mailing list <[e-mail]>, Loa Andersson <[e-mail]>, Scott Bradner <[e-mail]>, Deborah Brungard <[e-mail]>, Stewart Bryant <[e-mail]>, Adrian Farrel <[e-mail]>, Danny McPherson <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: Updated Liaison to ITU-T SG15 
From: George Swallow <[e-mail]>
Date: Thu, 14 Sep 2006 12:23:25 -0400
Message-Id: <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=6389; t=1158250987; x=1159114987; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:George=20Swallow=20<[e-mail]> |Subject:Updated=20Liaison=20to=20ITU-T=20SG15=20 |To:Greg=20Jones=20<[e-mail]>; X=v=3Dcisco.com=3B=20h=3DucrXgxnUFLBKbA4teKEn31O4ArA=3D; b=AVtUQeQlfzTkT2gno5CFjbk1KeQoncjH7B1B7HiiOKa8R3W2TAPuzFYQEiHUMoXvEny2lXGl 79WhrtW/94LPZZ7JtavtIVosNk2ztuPgQC2ouQPq8GbQQg0b1cPxTxFK;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; );

All -

There is a type-o in the liaison sent yesterday.  The second sentence of
the third paragraph should have been deleted.  An updated copy is
attached.

...George

========================================================================

Liaison Statement

Submission 
   Date:      2006-09-13

From:         Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; 
                 [e-mail])
              Scott Bradner  (IETF Liaison to ITU-T, [e-mail])
              Deborah Brungard  (IETF CCAMP WG Chair, [e-mail])
              Stewart Bryant (IETF PWE3 WG Chair, [e-mail])
              Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair,    
                [e-mail])
              Danny McPherson  (IETF PWE3 WG Chair, [e-mail])
              George Swallow (IETF MPLS WG Chair, [e-mail])
                
To:           ITU-T Study Group 15; Greg Jones  ([e-mail])

CC:           IESG  ([e-mail])
              IAB  ([e-mail])
              Steve Trowbridge  ([e-mail])
              Malcolm Betts  ([e-mail])
              Yoichi Maeda  ([e-mail])
              Ghani Abbas  ([e-mail])
              Houlin Zhao  ([e-mail])
              CCAMP mailing list ([e-mail])
              MPLS mailing list ([e-mail])
              PWE3 mailing list ([e-mail])


Re:           T-MPLS use of the MPLS Ethertypes

Response  
    Contact:  George Swallow  

Technical 
    Contact:  George Swallow

Purpose:      For action

Deadline:     2006-10-13


     We would like to thank you for your response to our liaison.  We
     feel that through the liaison activity and the Ottawa meeting we
     have entered into a productive and useful dialogue.  We are
     particularly pleased by your positive reaction to most of our
     concerns.

     We do, however, once again, request documentation of the problem
     that T-MPLS solves.  We feel that this documentation is
     fundamental to a proper review of the T-MPLS architecture,
     protocol requirements, and any future solutions, and we advise
     the ITU-T not to present any T-MPLS Recommendations for consent
     until work on a T-MPLS problem statement is well
     advanced. Further, a full reference diagram of the interfaces and
     services of the T-MPLS network would be most useful.  We
     understand that the direct adaptation of an IP/MPLS client over a
     T-MPLS server is still at a very preliminary stage.  However,
     some understanding of the client/server relationship is necessary
     in order to adequately evaluate architectural decisions currently
     being made in G.8110.1.

     The most immediate concern is the proposed use of the MPLS
     Ethertypes.  

     First we would like to call your attention to the fact that we
     are in the process of modifying the semantics of the two
     Ethertypes used by MPLS.  Currently their designations are "MPLS
     Unicast" (8847) and "MPLS Multicast" (8848).  The new semantics
     will be "Downstream Assigned" (8847) and "Upstream Assigned"
     (8848)".  On a practical level, they will still be used for
     Unicast and Multicast respectively, however the change has been
     made to clarify which Label Switch Router (LSR) controls each
     label space.

     Each of these label spaces is shared by all MPLS applications.
     Each space is managed by a label-manager which is responsible for
     label allocation and reclamation.  When a packet is received at
     the downstream LSR with Ethertype 8847 it is looked up in a table
     managed by the downstream router.  Conversely when a packet is
     received at the downstream LSR with Ethertype 8848 it is looked
     up in a table managed by the upstream router.

     In your liaison to the MFA Forum dated 19-23 June 2006 you say,

        T-MPLS is intended to be a separate layer network with respect
        to MPLS. However, T- MPLS will use the same data-link protocol
        ID (e.g. EtherType), frame format and forwarding semantics for
        as those defined for MPLS frames.  T-MPLS and MPLS cannot
        coexist on the same "interface" (for example they could not
        coexist on a single Ethernet VLAN, however they could be
        multiplexed on to a common Ethernet PHY using separate VLANs).

     On the face of it, this statement implies that MPLS and T-MPLS
     are two different things, but that you wish to identify them both
     using the same Ethertype.  The Ethertype is the primary means for
     multiplexing and distinguishing protocols over Ethernet.  The
     Ethertype identifies the protocol entity that will receive a
     packet at the layer above.  VLANs on the other hand are primarily
     intended as a service level interface, allowing multiple virtual
     LANs over a single bridged domain.  .

     If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is
     in fact a separate layer network, then it should be identified by
     its own Ethertype(s), Clear and unambiguous identification is in
     the best interest of all involved.  In particular, if T- MPLS is
     being architected in such a way that would prevent it from
     acquiring labels by interacting with a shared label manager, then
     separate Ethertypes would guarantee that there is no confusion as
     to which label spaces belong to T-MPLS.

     Note further that if T-MPLS is being architected in such a way
     that it can (or could) interact with a shared label manager and
     could co-exist over the same interface sharing the MPLS label
     spaces with other MPLS applications, then we would welcome use of
     the MPLS Ethertypes.

     We believe that a decision to use the MPLS Ethertypes to point to
     a label space other than as defined by the MPLS RFCs to be
     architecturally unsound and ultimately will prove to be limiting
     to the deployment options available in networks which employ both
     MPLS and T-MPLS.

     Sincerely,

        Loa Andersson 
        Scott Bradner
        Deborah Brungard
        Stewart Bryant
        Adrian Farrel 
        Danny McPherson
        George Swallow




Envelope-to: [e-mail]
Delivery-date: Wed, 13 Sep 2006 20:08:07 +0000
To: Greg Jones <[e-mail]>
Cc: IESG <[e-mail]>, IAB <[e-mail]>, Steve Trowbridge <[e-mail]>, Malcolm Betts <[e-mail]>, Yoichi Maeda <[e-mail]>, Ghani Abbas <[e-mail]>, Houlin Zhao <[e-mail]>, CCAMP mailing list <[e-mail]>, MPLS mailing list <[e-mail]>, PWE3 mailing list <[e-mail]>
Cc: Loa Andersson <[e-mail]>, Scott Bradner <[e-mail]>, Deborah Brungard <[e-mail]>, Stewart Bryant <[e-mail]>, Adrian Farrel <[e-mail]>, Danny McPherson <[e-mail]>, George Swallow <[e-mail]>, [e-mail]
From: George Swallow <[e-mail]>
Subject: Liaison to ITU-T SG15
Date: Wed, 13 Sep 2006 16:06:20 -0400
Message-Id: <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=6463; t=1158177965; x=1159041965; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:George=20Swallow=20<[e-mail]> |Subject:Liaison=20to=20ITU-T=20SG15 |To:Greg=20Jones=20<[e-mail]>; X=v=3Dcisco.com=3B=20h=3DtYerVQOY20ZZEewydYfLbbJbYkE=3D; b=LPj2dIN/WN+Mv0t7Xl2yoM8TMdqB9yc0c6NFkhvBmE4LIPIWDVUIquwfUmja/AgAPJOn+CJs SXmS/PZm/6ThVCESFKLjL6+XljBQyrxlHVMZe7+zSRidtN2F+Of831sB;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; );

Liaison Statement

Submission 
   Date:      2006-09-13

From:         Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; 
                 [e-mail])
              Scott Bradner  (IETF Liaison to ITU-T, [e-mail])
              Deborah Brungard  (IETF CCAMP WG Chair, [e-mail])
              Stewart Bryant (IETF PWE3 WG Chair, [e-mail])
              Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair,    
                [e-mail])
              Danny McPherson  (IETF PWE3 WG Chair, [e-mail])
              George Swallow (IETF MPLS WG Chair, [e-mail])
                
To:           ITU-T Study Group 15; Greg Jones  ([e-mail])

CC:           IESG  ([e-mail])
              IAB  ([e-mail])
              Steve Trowbridge  ([e-mail])
              Malcolm Betts  ([e-mail])
              Yoichi Maeda  ([e-mail])
              Ghani Abbas  ([e-mail])
              Houlin Zhao  ([e-mail])
              CCAMP mailing list ([e-mail])
              MPLS mailing list ([e-mail])
              PWE3 mailing list ([e-mail])


Re:           T-MPLS use of the MPLS Ethertypes

Response  
    Contact:  George Swallow  

Technical 
    Contact:  George Swallow

Purpose:      For action

Deadline:     2006-10-13


     We would like to thank you for your response to our liaison.  We
     feel that through the liaison activity and the Ottawa meeting we
     have entered into a productive and useful dialogue.  We are
     particularly pleased by your positive reaction to most of our
     concerns.

     We do, however, once again, request documentation of the problem
     that T-MPLS solves.  We feel that this documentation is
     fundamental to a proper review of the T-MPLS architecture,
     protocol requirements, and any future solutions, and we advise
     the ITU-T not to present any T-MPLS Recommendations for consent
     until work on a T-MPLS problem statement is well
     advanced. Further, a full reference diagram of the interfaces and
     services of the T-MPLS network would be most useful.  We
     understand that the direct adaptation of an IP/MPLS client over a
     T-MPLS server is still at a very preliminary stage.  However,
     some understanding of the client/server relationship is necessary
     in order to adequately evaluate architectural decisions currently
     being made in G.8110.1.

     The most immediate concern is the proposed use of the MPLS
     Ethertypes.  In your liaison to the MFA Forum dated 19-23 June
     2006 you say,

     First we would like to call your attention to the fact that we
     are in the process of modifying the semantics of the two
     Ethertypes used by MPLS.  Currently their designations are "MPLS
     Unicast" (8847) and "MPLS Multicast" (8848).  The new semantics
     will be "Downstream Assigned" (8847) and "Upstream Assigned"
     (8848)".  On a practical level, they will still be used for
     Unicast and Multicast respectively, however the change has been
     made to clarify which Label Switch Router (LSR) controls each
     label space.

     Each of these label spaces is shared by all MPLS applications.
     Each space is managed by a label-manager which is responsible for
     label allocation and reclamation.  When a packet is received at
     the downstream LSR with Ethertype 8847 it is looked up in a table
     managed by the downstream router.  Conversely when a packet is
     received at the downstream LSR with Ethertype 8848 it is looked
     up in a table managed by the upstream router.

     In your liaison to the MFA Forum dated 19-23 June 2006 you say,

        T-MPLS is intended to be a separate layer network with respect
        to MPLS. However, T- MPLS will use the same data-link protocol
        ID (e.g. EtherType), frame format and forwarding semantics for
        as those defined for MPLS frames.  T-MPLS and MPLS cannot
        coexist on the same "interface" (for example they could not
        coexist on a single Ethernet VLAN, however they could be
        multiplexed on to a common Ethernet PHY using separate VLANs).

     On the face of it, this statement implies that MPLS and T-MPLS
     are two different things, but that you wish to identify them both
     using the same Ethertype.  The Ethertype is the primary means for
     multiplexing and distinguishing protocols over Ethernet.  The
     Ethertype identifies the protocol entity that will receive a
     packet at the layer above.  VLANs on the other hand are primarily
     intended as a service level interface, allowing multiple virtual
     LANs over a single bridged domain.  .

     If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is
     in fact a separate layer network, then it should be identified by
     its own Ethertype(s), Clear and unambiguous identification is in
     the best interest of all involved.  In particular, if T- MPLS is
     being architected in such a way that would prevent it from
     acquiring labels by interacting with a shared label manager, then
     separate Ethertypes would guarantee that there is no confusion as
     to which label spaces belong to T-MPLS.

     Note further that if T-MPLS is being architected in such a way
     that it can (or could) interact with a shared label manager and
     could co-exist over the same interface sharing the MPLS label
     spaces with other MPLS applications, then we would welcome use of
     the MPLS Ethertypes.

     We believe that a decision to use the MPLS Ethertypes to point to
     a label space other than as defined by the MPLS RFCs to be
     architecturally unsound and ultimately will prove to be limiting
     to the deployment options available in networks which employ both
     MPLS and T-MPLS.

     Sincerely,

        Loa Andersson 
        Scott Bradner
        Deborah Brungard
        Stewart Bryant
        Adrian Farrel 
        Danny McPherson
        George Swallow



========================================================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719





Envelope-to: [e-mail]
Delivery-date: Tue, 12 Sep 2006 12:41:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D668.70B66A24"
Subject: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling
Date: Tue, 12 Sep 2006 08:39:08 -0400
Message-ID: <[e-mail]>
Thread-Topic: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling
Thread-Index: AcbWaHExSeMNt+mUQjmXewMnDSPEqg==
From: "Pandian, Vijay" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6D668.70B66A24
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
What is the rationale behind defining a new C-Type ( C-Type =3D 2, =
suggested value, TBA by IANA) for the PROTECTION Object in the e2e draft =
instead of extending C-Type =3D 1 defined in rfc3473?
=20
Should we consider C-Type =3D 1 as obsolete?
=20
Regards,
=20
Vijay
=20

------_=_NextPart_001_01C6D668.70B66A24
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D026182912-12092006>What =
is the=20
rationale behind defining a new C-Type ( C-Type =3D 2, suggested value, =
TBA by=20
IANA) for the PROTECTION Object in the e2e draft instead of=20
extending&nbsp;C-Type =3D 1 defined in rfc3473?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D026182912-12092006>Should =
we consider=20
C-Type =3D 1 as obsolete?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006>Vijay</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D026182912-12092006></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6D668.70B66A24--



Envelope-to: [e-mail]
Delivery-date: Fri, 08 Sep 2006 14:51:47 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-15.txt 
Message-Id: <[e-mail]>
Date: Fri, 08 Sep 2006 10:50:01 -0400

--NextPart

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		: Generalized Multiprotocol Label Switching (GMPLS)Label Switching Router (LSR) Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-15.txt
	Pages		: 42
	Date		: 2006-9-8
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-lsr-mib-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 08 Sep 2006 14:51:38 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-11.txt 
Message-Id: <[e-mail]>
Date: Fri, 08 Sep 2006 10:50:01 -0400

--NextPart

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		: Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-11.txt
	Pages		: 9
	Date		: 2006-9-8
	
This document defines a Management Information Base (MIB) module
   which contains Textual Conventions to represent commonly used
   Generalized Multiprotocol Label Switching (GMPLS) management
   information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
   be imported and used in GMPLS related MIB modules that would
   otherwise define their own representations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-tc-mib-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-tc-mib-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 08 Sep 2006 14:51:30 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-00.txt 
Message-Id: <[e-mail]>
Date: Fri, 08 Sep 2006 10:50:01 -0400

--NextPart

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		: Operating Virtual Concatenation (VCAT) and 
                          the Link Capacity Adjustment Scheme (LCAS) 
                          with Generalized Multi-Protocol Label Switching (GMPLS) 

	Author(s)	: G. Bernstein, et al.
	Filename	: draft-ietf-ccamp-gmpls-vcat-lcas-00.txt
	Pages		: 14
	Date		: 2006-9-8
	
This document describes requirements for, and use of, the Generalized 
Multi-Protocol Label Switching (GMPLS) control plane in conjunction 
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 
mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 
which can be used for hitless dynamic resizing of the inverse 
multiplex group.  These techniques apply to the Optical Transport 
Network (OTN), Synchronous Optical Network (SONET), Synchronous 
Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) 
signals. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-vcat-lcas-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-vcat-lcas-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Fri, 08 Sep 2006 14:51:22 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-16.txt 
Message-Id: <[e-mail]>
Date: Fri, 08 Sep 2006 10:50:01 -0400

--NextPart

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		: Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-te-mib-16.txt
	Pages		: 59
	Date		: 2006-9-8
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for Generalized
   Multiprotocol Label Switching (GMPLS) based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-te-mib-16.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-16.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-16.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Thu, 07 Sep 2006 22:52:03 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-00.txt 
Message-Id: <[e-mail]>
Date: Thu, 07 Sep 2006 18:50:02 -0400

--NextPart

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		: Graceful Shutdown in GMPLS Traffic Engineering Networks
	Author(s)	: Z. Ali, et al.
	Filename	: draft-ietf-ccamp-mpls-graceful-shutdown-00.txt
	Pages		: 9
	Date		: 2006-9-7
	
GMPLS-TE Graceful shutdown is a method for explicitly notifying the 
nodes in a Traffic Engineering (TE) enabled network that the TE 
capability on a link or on an entire Label Switching Router (LSR) is 
going to be disabled. GMPLS-TE graceful shutdown mechanisms are 
tailored towards addressing the planned outage in the network.  
    
This document provides requirements and protocol mechanisms so as to 
reduce/eliminate traffic disruption in the event of a planned 
shutdown of a network resource. These operations are equally 
applicable for both MPLS and its GMPLS extensions.  

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-mpls-graceful-shutdown-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-graceful-shutdown-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 19:51:06 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-05.txt 
Message-Id: <[e-mail]>
Date: Wed, 06 Sep 2006 15:50:02 -0400

--NextPart

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		: GMPLS - Communication of Alarm Information
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-alarm-spec-05.txt
	Pages		: 19
	Date		: 2006-9-6
	
This document describes an extension to Generalized MPLS (Multi-
Protocol Label Switching) signaling to support communication of alarm
information.  GMPLS signaling already supports the control of alarm
reporting, but not the communication of alarm information.  This
document presents both a functional description and GMPLS-RSVP
specifics of such an extension.  This document also proposes
modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473 "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions" through the addition of new,
optional protocol elements. It does not change, and is fully backward
compatible with the procedures specified in RFC 3473.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-gmpls-alarm-spec-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-alarm-spec-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 17:41:25 +0000
Message-ID: <012601c6d1db$91afd320$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lucy Yong" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Potential for liaison *to* IEEE
Date: Wed, 6 Sep 2006 18:38:08 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Lucy,

> In 66th IETF meeting, there is an intention to send a liaison letter to 
> IEEE
> regarding what control plane could control/manage in Ethernet data plane.

I do not recall any intention by CCAMP to send a liaison at this time.

The process that we will follow in CCAMP is clearly (I believe) documented 
in my email of 17th July to the CCAMP and GELS mailing lists. See 
https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html

You will see that a liaison from CCAMP does not show up until step 4 in the 
process.

> This liaison from IEEE clearly states that IEEE has not examined MAC 
> address
> encapsulation in conjunction with VLAN tagging, thus this is not accepted
> now. It also clearly states that using two VLAN tags simultaneously is not
> allowed.
>
> Hence, now, standard Ethernet data plane bridge/switch based on MAC or
> VLAN only.
> Do we still need a liaison to IEEE?

Yes, when we get to step 4 in the process we will still need a liaison.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 17:41:17 +0000
Message-ID: <012901c6d1db$a01101f0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Cross-posting on GELS: STOP AND THINK
Date: Wed, 6 Sep 2006 18:40:44 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi all,

Stop and think. You are all clever people.

Don't just hit reply. Check the recipients before you send.

Please limit your postings discussing the GELS data plane to the GELS 
mailing list.

Do not send mail on this topic to the CCAMP list.

Thanks.

Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 17:30:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 20:26:56 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbR4Nue2GF46UEtSDCxZSR8ObNMcAAAKB8w
From: "Nurit Sprecher" <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Lucy Yong" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Nurit Sprecher" <[e-mail]>

IMO, it is the same.

The 802.1ad defines that "A conformant S-VLAN component may implement
any of the options specified for a VLAN-aware bridge component (5.4.1),
and may
a) allow translation of VIDs through support of a VID Translation Table
(6.7) on each Port.".=20


-----Original Message-----
From: Loa Andersson [mailto:[e-mail]]=20
Sent: Wednesday, September 06, 2006 19:19
To: Nurit Sprecher
Cc: Don Fedyk; Lucy Yong; Adrian Farrel; [e-mail];
[e-mail]
Subject: Re: IEEE 802.1 WG liaison letter to the IETF

All,

I've been looking at this sentence in the liaison:

Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at
S-tagged service interfaces, as an option, by the IEEE Std 802.1ad
Provider Bridging amendment to IEEE Std 802.1Q.

Could someone explain if there is a difference between a "S-tagged
service interface" and a "S-tagged interface"?

/Loa

Nurit Sprecher wrote:
> Hi Don,
> I did not say the that liaison says that the IET should focus on the=20
> 12 bit label encoding technique. I said that the IEEE confirmed that=20
> the 12-bit S-VID translation is a standard behavior.
> The IETF got a decision not to define the data plane but to get a=20
> confirmation from the IEEE for the standard behavior. This was=20
> achieved regarding the 12-bit label encoding technique and we can go=20
> on with the work already initiated on this.
> Regards,
> Nurit.
>=20
> -----Original Message-----
> From: Don Fedyk [mailto:[e-mail]]
> Sent: Wednesday, September 06, 2006 18:14
> To: Nurit Sprecher; Lucy Yong; Adrian Farrel; [e-mail];=20
> [e-mail]
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Nurit
>=20
> Please do not try to interpret the liaison. The Liaison says nothing=20
> about
>=20
> "The IETF should now focus on the 12 bit label encoding technique".
>=20
> It actually states:
>=20
> "The protocol entities that make use of a given Ethertype are=20
> characterized not just by the format of packets 'on the wire' and=20
> rules for their interchange, but also by their defined interfaces to=20
> adjacent entities in the interface stack and the MAC relay entity as=20
> well as by their local management interface interactions"
>=20
> In other words just looking like an Ethernet packet with a 12 bit VID=20
> (or not) on the wire is not the only criterion. The behavior an impact

> on the Ethernet switch needs to be taken into account. In other words=20
> all schemes including your 12 bit VID still need to be discussed to=20
> the impact on the interfaces as relays on Ethernet hardware.
>=20
> Regards,
> Don
> =20
>=20
>> -----Original Message-----
>> From: [e-mail]
>> This liaison was imitated by the IEEE intentionally to address the=20
>> same question that  we wanted to ask the IEEE.
>> The liaison clearly states that (currently) the only standard=20
>> behavior
>=20
>> is the 12-bit VID translation, and the IETF should now focus on the=20
>> 12-bit label encoding technique for GELS.
>> Regards,
>> Nurit.
>>
> <SNIP>
>=20
>=20
>=20
>=20


--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                           [e-mail]





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 17:21:55 +0000
Message-ID: <[e-mail]>
Date: Wed, 06 Sep 2006 19:18:40 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Nurit Sprecher <[e-mail]>
CC: Don Fedyk <[e-mail]>, Lucy Yong <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IEEE 802.1 WG liaison letter to the IETF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I've been looking at this sentence in the liaison:

Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported
at S-tagged service interfaces, as an option, by the
IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q.

Could someone explain if there is a difference between a "S-tagged
service interface" and a "S-tagged interface"?

/Loa

Nurit Sprecher wrote:
> Hi Don,
> I did not say the that liaison says that the IET should focus on the 12
> bit label encoding technique. I said that the IEEE confirmed that the
> 12-bit S-VID translation is a standard behavior. 
> The IETF got a decision not to define the data plane but to get a
> confirmation from the IEEE for the standard behavior. This was achieved
> regarding the 12-bit label encoding technique and we can go on with the
> work already initiated on this.
> Regards,
> Nurit.
> 
> -----Original Message-----
> From: Don Fedyk [mailto:[e-mail]] 
> Sent: Wednesday, September 06, 2006 18:14
> To: Nurit Sprecher; Lucy Yong; Adrian Farrel; [e-mail];
> [e-mail]
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
> 
> Nurit
> 
> Please do not try to interpret the liaison. The Liaison says nothing
> about 
> 
> "The IETF should now focus on the 12 bit label encoding technique".
> 
> It actually states:
> 
> "The protocol entities that make use of a given Ethertype are
> characterized not just by the format of packets 'on the wire' and rules
> for their interchange, but also by their defined interfaces to adjacent
> entities in the interface stack and the MAC relay entity as well as by
> their local management interface interactions"
> 
> In other words just looking like an Ethernet packet with a 12 bit VID
> (or not) on the wire is not the only criterion. The behavior an impact
> on the Ethernet switch needs to be taken into account. In other words
> all schemes including your 12 bit VID still need to be discussed to the
> impact on the interfaces as relays on Ethernet hardware.
> 
> Regards,
> Don 
>  
> 
>> -----Original Message-----
>> From: [e-mail]
>> This liaison was imitated by the IEEE intentionally to address the 
>> same question that  we wanted to ask the IEEE.
>> The liaison clearly states that (currently) the only standard behavior
> 
>> is the 12-bit VID translation, and the IETF should now focus on the 
>> 12-bit label encoding technique for GELS.
>> Regards,
>> Nurit.
>>
> <SNIP>
> 
> 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                           [e-mail]



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 17:01:52 +0000
Date: Wed, 06 Sep 2006 12:01:37 -0500
From: Lucy Yong <[e-mail]>
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
To: 'Nurit Sprecher' <[e-mail]>, 'Don Fedyk' <[e-mail]>, 'Adrian Farrel' <[e-mail]>, [e-mail], [e-mail]
Message-id: <001501c6d1d6$1daa62b0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUAAAMTuwAAFyVzA=

Nurit&Don,

It seems that label encoding technique could relate to the data plane
semantics based on your discussions. The question is if IEEE allows and
follows other SDO's standardized VLAN label encoding?

Regards,
Lucy

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Nurit Sprecher
Sent: Wednesday, September 06, 2006 12:42 PM
To: Don Fedyk; Lucy Yong; Adrian Farrel; [e-mail];
[e-mail]
Cc: Nurit Sprecher
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

Hi Don,
I did not say the that liaison says that the IET should focus on the 12
bit label encoding technique. I said that the IEEE confirmed that the
12-bit S-VID translation is a standard behavior. 
The IETF got a decision not to define the data plane but to get a
confirmation from the IEEE for the standard behavior. This was achieved
regarding the 12-bit label encoding technique and we can go on with the
work already initiated on this.
Regards,
Nurit.

-----Original Message-----
From: Don Fedyk [mailto:[e-mail]] 
Sent: Wednesday, September 06, 2006 18:14
To: Nurit Sprecher; Lucy Yong; Adrian Farrel; [e-mail];
[e-mail]
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

Nurit

Please do not try to interpret the liaison. The Liaison says nothing
about 

"The IETF should now focus on the 12 bit label encoding technique".

It actually states:

"The protocol entities that make use of a given Ethertype are
characterized not just by the format of packets 'on the wire' and rules
for their interchange, but also by their defined interfaces to adjacent
entities in the interface stack and the MAC relay entity as well as by
their local management interface interactions"

In other words just looking like an Ethernet packet with a 12 bit VID
(or not) on the wire is not the only criterion. The behavior an impact
on the Ethernet switch needs to be taken into account. In other words
all schemes including your 12 bit VID still need to be discussed to the
impact on the interfaces as relays on Ethernet hardware.

Regards,
Don 
 

> -----Original Message-----
> From: [e-mail]
> This liaison was imitated by the IEEE intentionally to address the 
> same question that  we wanted to ask the IEEE.
> The liaison clearly states that (currently) the only standard behavior

> is the 12-bit VID translation, and the IETF should now focus on the 
> 12-bit label encoding technique for GELS.
> Regards,
> Nurit.
> 
<SNIP>



_______________________________________________
gels mailing list
[e-mail]
https://rtg.ietf.org/mailman/listinfo/gels





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:56:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 19:52:55 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAAAAcokkAABdMzg
From: "Nurit Sprecher" <[e-mail]>
To: "Don Fedyk" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>

You are right. As I already mentioned, it happened by mistake.


-----Original Message-----
From: Don Fedyk [mailto:[e-mail]]=20
Sent: Wednesday, September 06, 2006 18:53
To: Nurit Sprecher
Cc: Adrian Farrel; [e-mail]
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

Hi Nurit=20

I believe the Chairs asked us to not to cross post to both GELS and
CCAMP as well so the whole discussion of Data Plane goes to GELS only.

Regards,
Don =20

> -----Original Message-----
> From: Nurit Sprecher [mailto:[e-mail]]
> Sent: Wednesday, September 06, 2006 1:43 PM
> To: Fedyk, Don (BL60:1A00)
> Cc: Adrian Farrel; [e-mail]; Nurit Sprecher
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Thanks. I did not realize that the GELS is not Cced.=20
>=20
> -----Original Message-----
> From: Don Fedyk [mailto:[e-mail]]
> Sent: Wednesday, September 06, 2006 18:26
> To: Nurit Sprecher; Adrian Farrel; [e-mail]
> Cc: [e-mail]
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Nurit
>=20
> We should not talk about the IEEE data plane on the CCAMP list please=20
> see Adrian's message for a reminder:
>=20
> https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html
>=20
> So please take your discussion to GELS. You and I can continue to=20
> Disagree there if you like.
>=20
> Regards,
> Don
>=20
> <snip>
>=20
>=20
>=20





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:53:31 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 12:53:18 -0400
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAAAAcokkA==
From: "Don Fedyk" <[e-mail]>
To: "Nurit Sprecher" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Nurit=20

I believe the Chairs asked us to not to cross post to both GELS and
CCAMP as well so the whole discussion of Data Plane goes to GELS only.

Regards,
Don =20

> -----Original Message-----
> From: Nurit Sprecher [mailto:[e-mail]]=20
> Sent: Wednesday, September 06, 2006 1:43 PM
> To: Fedyk, Don (BL60:1A00)
> Cc: Adrian Farrel; [e-mail]; Nurit Sprecher
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Thanks. I did not realize that the GELS is not Cced.=20
>=20
> -----Original Message-----
> From: Don Fedyk [mailto:[e-mail]]
> Sent: Wednesday, September 06, 2006 18:26
> To: Nurit Sprecher; Adrian Farrel; [e-mail]
> Cc: [e-mail]
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Nurit
>=20
> We should not talk about the IEEE data plane on the CCAMP=20
> list please see Adrian's message for a reminder:=20
>=20
> https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html
>=20
> So please take your discussion to GELS. You and I can=20
> continue to Disagree there if you like. =20
>=20
> Regards,
> Don=20
>=20
> <snip>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:46:14 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 19:43:12 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnwAABDzAA=
From: "Nurit Sprecher" <[e-mail]>
To: "Don Fedyk" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Nurit Sprecher" <[e-mail]>

Thanks. I did not realize that the GELS is not Cced.=20

-----Original Message-----
From: Don Fedyk [mailto:[e-mail]]=20
Sent: Wednesday, September 06, 2006 18:26
To: Nurit Sprecher; Adrian Farrel; [e-mail]
Cc: [e-mail]
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

Nurit

We should not talk about the IEEE data plane on the CCAMP list please
see Adrian's message for a reminder:=20

https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html

So please take your discussion to GELS. You and I can continue to
Disagree there if you like. =20

Regards,
Don=20

<snip>=20





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:45:31 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 19:42:01 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUAAAMTuw
From: "Nurit Sprecher" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, "Lucy Yong" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Nurit Sprecher" <[e-mail]>

Hi Don,
I did not say the that liaison says that the IET should focus on the 12
bit label encoding technique. I said that the IEEE confirmed that the
12-bit S-VID translation is a standard behavior.=20
The IETF got a decision not to define the data plane but to get a
confirmation from the IEEE for the standard behavior. This was achieved
regarding the 12-bit label encoding technique and we can go on with the
work already initiated on this.
Regards,
Nurit.

-----Original Message-----
From: Don Fedyk [mailto:[e-mail]]=20
Sent: Wednesday, September 06, 2006 18:14
To: Nurit Sprecher; Lucy Yong; Adrian Farrel; [e-mail];
[e-mail]
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

Nurit

Please do not try to interpret the liaison. The Liaison says nothing
about=20

"The IETF should now focus on the 12 bit label encoding technique".

It actually states:

"The protocol entities that make use of a given Ethertype are
characterized not just by the format of packets 'on the wire' and rules
for their interchange, but also by their defined interfaces to adjacent
entities in the interface stack and the MAC relay entity as well as by
their local management interface interactions"

In other words just looking like an Ethernet packet with a 12 bit VID
(or not) on the wire is not the only criterion. The behavior an impact
on the Ethernet switch needs to be taken into account. In other words
all schemes including your 12 bit VID still need to be discussed to the
impact on the interfaces as relays on Ethernet hardware.

Regards,
Don=20
=20

> -----Original Message-----
> From: [e-mail]
> This liaison was imitated by the IEEE intentionally to address the=20
> same question that  we wanted to ask the IEEE.
> The liaison clearly states that (currently) the only standard behavior

> is the 12-bit VID translation, and the IETF should now focus on the=20
> 12-bit label encoding technique for GELS.
> Regards,
> Nurit.
>=20
<SNIP>





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:26:04 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 12:25:31 -0400
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUAABZgnw
From: "Don Fedyk" <[e-mail]>
To: "Nurit Sprecher" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Nurit

We should not talk about the IEEE data plane on the CCAMP list please
see Adrian's message for a reminder:=20

https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00489.html

So please take your discussion to GELS. You and I can continue to
Disagree there if you like. =20

Regards,
Don=20

<snip>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:15:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 12:14:28 -0400
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROAAAYDNUA==
From: "Don Fedyk" <[e-mail]>
To: "Nurit Sprecher" <[e-mail]>, "Lucy Yong" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>

Nurit

Please do not try to interpret the liaison. The Liaison says nothing
about=20

"The IETF should now focus on the 12 bit label encoding technique".

It actually states:

"The protocol entities that make use of a given Ethertype are
characterized not just by the format of packets 'on the wire' and rules
for their interchange, but also by their defined interfaces to adjacent
entities in the interface stack and the MAC relay entity as well as by
their local management interface interactions"

In other words just looking like an Ethernet packet with a 12 bit VID
(or not) on the wire is not the only criterion. The behavior an impact
on the Ethernet switch needs to be taken into account. In other words
all schemes including your 12 bit VID still need to be discussed to the
impact on the interfaces as relays on Ethernet hardware.

Regards,
Don=20
=20

> -----Original Message-----
> From: [e-mail]=20
> This liaison was imitated by the IEEE intentionally to=20
> address the same question that  we wanted to ask the IEEE.=20
> The liaison clearly states that (currently) the only standard=20
> behavior is the 12-bit VID translation, and the IETF should=20
> now focus on the 12-bit label encoding technique for GELS.
> Regards,
> Nurit.
>=20
<SNIP>



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 16:07:50 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 19:04:12 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoAAAClbUA==
From: "Nurit Sprecher" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Nurit Sprecher" <[e-mail]>

Hi Don,=20
It is clearly stated in the liaison that  "We have not examined the
detailed architectural ramifications of MAC address encapsulation in
conjunction with VLAN tagging, beyond the uses presently being
standardized as P802.1ah Provider Backbone Bridging.". The IEEE should
still approve this kind of behavior (turning of broadcast and othe
linkages, etc. as you mention below). That was exactly the decision in
the last IETF meeting.=20
In the last IETF CCAMP meeting it was decided that any further work on
GELS should first be approved by the IEEE 802.1 community. Otherwise, we
re-start with the discussion=20
Regards,
Nurit.

-----Original Message-----
From: Don Fedyk [mailto:[e-mail]]=20
Sent: Wednesday, September 06, 2006 17:55
To: Nurit Sprecher; Adrian Farrel; [e-mail]
Cc: [e-mail]
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

Hi Nurit=20

It is true that the data plane 12-bit S-VID translation is part of
standards, but then so is using a VID/MAC as a static configured path
known as PBT.=20

However in order to have the above schemes work with the existing
Ethernet control plane enabled at a minimum partitioning of the VID
space, turning of broadcast and other linkages between the Ethernet
control plane still need to be standardized. We have discussed all this
before.

Regards,
Don=20



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Nurit Sprecher
> Sent: Wednesday, September 06, 2006 12:37 PM
> To: Adrian Farrel; [e-mail]
> Cc: Nurit Sprecher; [e-mail]
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Hi,
> Please note that according to the liaison from the IEEE, currently the

> only standard behavior is the 12-bit S-VID translation.
> That means that we can go on with the work done on the 12-bits=20
> Ethernet label encoding technique. We have the certification.
> Regards,
> Nurit.
>=20
>=20
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, September 06, 2006 16:05
> To: [e-mail]
> Subject: Fw: IEEE 802.1 WG liaison letter to the IETF
>=20
> Hi,
>=20
> Those of you working on GELS stuff may find material in this liaison=20
> (which will inevitably also get posted on the IETF site).
>=20
> Adrian
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[e-mail]>
> To: "IESG" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; "Tony Jeffree"=20
> <[e-mail]>
> Sent: Wednesday, September 06, 2006 2:55 PM
> Subject: IEEE 802.1 WG liaison letter to the IETF
>=20
>=20
>=20
> The IEEE 802.1 Working Group approved the following liaison letter to=20
> the IETF, containing clarifications in response to several queries=20
> related to the use of IEEE 802.1Q VLAN tags.
>=20
>
http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m
ef-dsl-forum-0706.pdf
>=20
> Please distribute this letter to the interested Working Groups that=20
> are not included in the distribution list.
>=20
> Dan
> (wearing the hat of IEEE 802.1 WG liaison to the IETF)
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 15:55:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 11:54:48 -0400
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSwAAEpNoA=
From: "Don Fedyk" <[e-mail]>
To: "Nurit Sprecher" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi Nurit=20

It is true that the data plane 12-bit S-VID translation is part of
standards, but then so is using a VID/MAC as a static configured path
known as PBT.=20

However in order to have the above schemes work with the existing
Ethernet control plane enabled at a minimum partitioning of the VID
space, turning of broadcast and other linkages between the Ethernet
control plane still need to be standardized. We have discussed all this
before.

Regards,
Don=20



> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Nurit Sprecher
> Sent: Wednesday, September 06, 2006 12:37 PM
> To: Adrian Farrel; [e-mail]
> Cc: Nurit Sprecher; [e-mail]
> Subject: RE: IEEE 802.1 WG liaison letter to the IETF
>=20
> Hi,
> Please note that according to the liaison from the IEEE,=20
> currently the only standard behavior is the 12-bit S-VID translation.=20
> That means that we can go on with the work done on the=20
> 12-bits Ethernet label encoding technique. We have the certification.
> Regards,
> Nurit.
>=20
>=20
> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, September 06, 2006 16:05
> To: [e-mail]
> Subject: Fw: IEEE 802.1 WG liaison letter to the IETF
>=20
> Hi,
>=20
> Those of you working on GELS stuff may find material in this=20
> liaison (which will inevitably also get posted on the IETF site).
>=20
> Adrian
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[e-mail]>
> To: "IESG" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; "Tony Jeffree"=20
> <[e-mail]>
> Sent: Wednesday, September 06, 2006 2:55 PM
> Subject: IEEE 802.1 WG liaison letter to the IETF
>=20
>=20
>=20
> The IEEE 802.1 Working Group approved the following liaison=20
> letter to the IETF, containing clarifications in response to=20
> several queries related to the use of IEEE 802.1Q VLAN tags.
>=20
> http://www.ieee802.org/1/files/public/docs2006/liaison-contrib
-to-ietf-m
> ef-dsl-forum-0706.pdf
>=20
> Please distribute this letter to the interested Working=20
> Groups that are not included in the distribution list.
>=20
> Dan
> (wearing the hat of IEEE 802.1 WG liaison to the IETF)
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 15:54:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 18:51:32 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpAAANpROA=
From: "Nurit Sprecher" <[e-mail]>
To: "Lucy Yong" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Nurit Sprecher" <[e-mail]>

This liaison was imitated by the IEEE intentionally to address the same
question that  we wanted to ask the IEEE.=20
The liaison clearly states that (currently) the only standard behavior
is the 12-bit VID translation, and the IETF should now focus on the
12-bit label encoding technique for GELS.
Regards,
Nurit.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Lucy Yong
Sent: Wednesday, September 06, 2006 17:46
To: 'Adrian Farrel'; [e-mail]; [e-mail]
Subject: RE: IEEE 802.1 WG liaison letter to the IETF

All,

In 66th IETF meeting, there is an intention to send a liaison letter to
IEEE regarding what control plane could control/manage in Ethernet data
plane.=20

This liaison from IEEE clearly states that IEEE has not examined MAC
address encapsulation in conjunction with VLAN tagging, thus this is not
accepted now.
It also clearly states that using two VLAN tags simultaneously is not
allowed.

Hence, now, standard Ethernet data plane bridge/switch based on MAC or
VLAN only.=20
Do we still need a liaison to IEEE?

Regards,
Lucy



=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Wednesday, September 06, 2006 9:05 AM
To: [e-mail]
Subject: Fw: IEEE 802.1 WG liaison letter to the IETF

Hi,

Those of you working on GELS stuff may find material in this liaison
(which will inevitably also get posted on the IETF site).

Adrian
----- Original Message -----
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "IESG" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Tony Jeffree"=20
<[e-mail]>
Sent: Wednesday, September 06, 2006 2:55 PM
Subject: IEEE 802.1 WG liaison letter to the IETF



The IEEE 802.1 Working Group approved the following liaison letter to
the IETF, containing clarifications in response to several queries
related to the use of IEEE 802.1Q VLAN tags.

http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m
ef-dsl-forum-0706.pdf

Please distribute this letter to the interested Working Groups that are
not included in the distribution list.

Dan
(wearing the hat of IEEE 802.1 WG liaison to the IETF)








_______________________________________________
gels mailing list
[e-mail]
https://rtg.ietf.org/mailman/listinfo/gels





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 15:45:52 +0000
Date: Wed, 06 Sep 2006 10:45:32 -0500
From: Lucy Yong <[e-mail]>
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
To: 'Adrian Farrel' <[e-mail]>, [e-mail], [e-mail]
Message-id: <001401c6d1cb$7cccca40$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcbRvleUT//9kWH6RDSiyChwOn4NKgACDbpA

All,

In 66th IETF meeting, there is an intention to send a liaison letter to IEEE
regarding what control plane could control/manage in Ethernet data plane. 

This liaison from IEEE clearly states that IEEE has not examined MAC address
encapsulation in conjunction with VLAN tagging, thus this is not accepted
now.
It also clearly states that using two VLAN tags simultaneously is not
allowed.

Hence, now, standard Ethernet data plane bridge/switch based on MAC or VLAN
only. 
Do we still need a liaison to IEEE?

Regards,
Lucy



 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adrian Farrel
Sent: Wednesday, September 06, 2006 9:05 AM
To: [e-mail]
Subject: Fw: IEEE 802.1 WG liaison letter to the IETF

Hi,

Those of you working on GELS stuff may find material in this liaison (which 
will inevitably also get posted on the IETF site).

Adrian
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "IESG" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Tony Jeffree" 
<[e-mail]>
Sent: Wednesday, September 06, 2006 2:55 PM
Subject: IEEE 802.1 WG liaison letter to the IETF



The IEEE 802.1 Working Group approved the following liaison letter to
the IETF, containing clarifications in response to several queries
related to the use of IEEE 802.1Q VLAN tags.

http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m
ef-dsl-forum-0706.pdf

Please distribute this letter to the interested Working Groups that are
not included in the distribution list.

Dan
(wearing the hat of IEEE 802.1 WG liaison to the IETF)











Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 15:40:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 18:36:46 +0200
Message-ID: <[e-mail]>
Thread-Topic: IEEE 802.1 WG liaison letter to the IETF
Thread-Index: AcbRxiolXU2gPEG8TdC5GktVFBdvxQACbTSw
From: "Nurit Sprecher" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Nurit Sprecher" <[e-mail]>, <[e-mail]>

Hi,
Please note that according to the liaison from the IEEE, currently the
only standard behavior is the 12-bit S-VID translation.=20
That means that we can go on with the work done on the 12-bits Ethernet
label encoding technique. We have the certification.
Regards,
Nurit.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Wednesday, September 06, 2006 16:05
To: [e-mail]
Subject: Fw: IEEE 802.1 WG liaison letter to the IETF

Hi,

Those of you working on GELS stuff may find material in this liaison
(which will inevitably also get posted on the IETF site).

Adrian
----- Original Message -----
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "IESG" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Tony Jeffree"=20
<[e-mail]>
Sent: Wednesday, September 06, 2006 2:55 PM
Subject: IEEE 802.1 WG liaison letter to the IETF



The IEEE 802.1 Working Group approved the following liaison letter to
the IETF, containing clarifications in response to several queries
related to the use of IEEE 802.1Q VLAN tags.

http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m
ef-dsl-forum-0706.pdf

Please distribute this letter to the interested Working Groups that are
not included in the distribution list.

Dan
(wearing the hat of IEEE 802.1 WG liaison to the IETF)











Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 14:06:52 +0000
Message-ID: <009401c6d1bd$9cbf88a0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: IEEE 802.1 WG liaison letter to the IETF
Date: Wed, 6 Sep 2006 15:04:31 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Those of you working on GELS stuff may find material in this liaison (which 
will inevitably also get posted on the IETF site).

Adrian
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "IESG" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Tony Jeffree" 
<[e-mail]>
Sent: Wednesday, September 06, 2006 2:55 PM
Subject: IEEE 802.1 WG liaison letter to the IETF



The IEEE 802.1 Working Group approved the following liaison letter to
the IETF, containing clarifications in response to several queries
related to the use of IEEE 802.1Q VLAN tags.

http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m
ef-dsl-forum-0706.pdf

Please distribute this letter to the interested Working Groups that are
not included in the distribution list.

Dan
(wearing the hat of IEEE 802.1 WG liaison to the IETF)








Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 13:59:40 +0000
Message-ID: <007d01c6d1bc$90e659b0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>
Subject: draft-ietf-ccamp-gmpls-lsr-mib-15.txt submitted
Date: Wed, 6 Sep 2006 14:57:26 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I have updated the GMPLS LSR MIB after IESG review and submitted it.

The changes are as follows.

Thanks,
Adrian

===
Lars Eggert - Comment

> Section 1., paragraph 2:
>>    Comments should be made directly to the CCAMP mailing list at
>>    [e-mail].
>
>  Remove.

Done

>Section 1.1., paragraph 2:
>>    LSRs may be migrated to be modeled and managed using the MIB modules
>>    in this document in order to migrate the LSRs to GMPLS support, or to
>>    take advandtage of additional MIB objects defined in these MIB
>
>  Nit: s/advandtage/advantage/

Done

>Section 4.2., paragraph 10:
>>    - Optionally specifying segment traffic parameters in the
>>      MPLS-LSR-STD-MIB module [RCF3813].
>
>  Nit: s/[RCF3813]./[RFC3813]./

Done

>Section 6., paragraph 10:
>>      -- RowPointer MUST point to the first accsesible column.
>
>  Nit: s/accsesible/accessible/

Done

>Section 7., paragraph 55:
>Section 7., paragraph 57:
>Section 7., paragraph 72:
>Section 7., paragraph 74:
>>        "The only valid value for unidrectional LSPs is forward(1)."
>
>  Nit: s/unidrectional/unidirectional/

Done

>Section 9., paragraph 7:
>>    if the network itself is secure (for example by using IPSec), even
>
>  Nit: s/IPSec),/IPsec),/

Done

>Section 10., paragraph 0:
>>    10. Acknowledgments
>
>  Nit: Typically after IANA considerations.

No change made.

>Section 10., paragraph 2:
>>    This document extends [RFC3813].
>
>  "Extends" as in "updates?" If so, must reflect in
>  headers/abstract/intro.

Text changed to "extends the MIB tables in [RFC3813]"

>Section 11., paragraph 3:
>>    New assignments can only be made via a Standards Action as specified 
>> in
>>    [RFC2434].
>
>  Missing Reference: 'RFC2434' is mentioned on line 1867, but not
>  defined

Added
===

Dan Romascanu - Comment

>>   DESCRIPTION
>>      "Initial version issued as part of RFC XXX."
>>    ::= { mplsStdMIB XXX }
>>-- RFC Editor. Please replace XXX above with the correct RFC number and
>>-- remove this note.
>>
>>-- RFC Editor. Please replace YYY above with the OID assigned by IANA
>>-- and remove this note
>
>The intention is I believe:
>
>    ::= { mplsStdMIB YYY }

Done

>Also:
>
>>    DESCRIPTION
>>      "Initial version issued as part of RFC XXX."
>>    ::= { mplsStdMIB XXX }
>>-- RFC Editor. Please replace XXX above with the correct RFC number and
>>-- remove this note.
>>
>>-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
>>-- and remove this note
>
>should rather be:
>
>    ::= { mplsStdMIB ZZZ }

Done

===

IANA - Comment

Text updated to reflect IANA's action






Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 13:20:23 +0000
Message-ID: <006801c6d1b7$1dd0ee90$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>
Subject: draft-ietf-ccamp-gmpls-tc-mib-11.txt submitted
Date: Wed, 6 Sep 2006 14:18:49 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I have just submitted a new revision of the GMPLS TC MIB updated after IESG 
review.

The changes are as follows.

Thanks,
Adrian

===
Lars Eggert - Comment

>Section 1., paragraph 3:
>>    Comments should be made directly to the CCAMP mailing list at
>>    [e-mail].
>
>  Nit: Remove.

Done

>Section 3., paragraph 23:
>>        For manually
>>        configured bidirecitonal LSPs, an arbitrary decision must be
>
>  Nit: s/bidirecitonal/bidirectional/

Done

>Section 5., paragraph 3:
>>    New assignments can only be made via a Standards Action as specified 
>> in
>>    [RFC2434].
>
>  Nit: Missing Reference: 'RFC2434' is mentioned on line 274, but not
>  defined

Added

===

IANA - Comment

Text updated to reflect IANA's action

===

Dan Romascanu - Comment

>>     -- This MIB module is contained in the OID sub-tree
>>      -- rooted at mplsStdMIB.
>>      "Initial version published as part of RFC XXX."
>>  ::= { mplsStdMIB XXX }
>>
>>-- RFC Editor. Please replace XXX above with the correct RFC number and
>>-- remove this note.
>>
>>-- RFC Editor. Please replace YYY above with the OID assigned by IANA
>>-- and remove this note
>
>should be:
>
>  ::= { mplsStdMIB YYY }

Done 





Envelope-to: [e-mail]
Delivery-date: Wed, 06 Sep 2006 13:07:19 +0000
Message-ID: <004d01c6d1b4$f77cfd80$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Ross Callon" <[e-mail]>
Subject: draft-ietf-ccamp-gmpls-te-mib-16.txt submitted
Date: Wed, 6 Sep 2006 14:02:53 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I have submitted this I-D updated after IESG review.

The changes are as follows.

Thanks,
Adrian

****************
draft-ietf-ccamp-gmpls-te-mib-15

===

Lars Eggert - Comment

>Section 1.1., paragraph 2:
>>    LSRs may be migrated to model and manage their TE LSPs using the MIB
>>    modules in this document in order to migrate the LSRs to GMPLS
>>    support, or to take advandtage of additional MIB objects defined in
>
>  Nit: s/advandtage/advantage/

Done

>Section 8., paragraph 185:
>>        If the value of
>>        gmplsTunnelErrorLastErrorType is protocol (2) the error should
>>        be interpreted in the context of the signling protocol
>
>  Nit: s/signling/signaling/

Done

>Section 8., paragraph 198:
>>          The notification rate applies to the sum
>>          of all notificaitons in the MPLS-TE-STD-MIB and
>
>  Nit: s/notificaitons/notifications/

Done

>Section 9., paragraph 7:
>>    if the network itself is secure (for example by using IPSec), even
>
>  Nit: s/IPSec),/IPsec),/

Done

>Section 12.1., paragraph 22:
>>    [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual
>>                Conventions for Multiprotocol Label Switching (MPLS)
>>                Management", draft-ietf-ccamp-gmpls-tc-mib, work in
>>                progress.
>
>  Nit: 'GMPLSTCMIB' is defined on line 2850, but not referenced

Removed

===

Russ Housley - Discuss

>  I don't understand gmplsTunnelLinkProtection.  I gather it is
> described in RFC3471.  However it seems like this ought to be
>  discussed in the security considerations.

Explanation in email to Russ resulted in this response. No editorial action 
taken.

>I had a DISCUSS based on this comment.  Thank for the explanation.  I've
>cleared the DISCUSS.
>
> Russ
>
> At 12:34 PM 8/29/2006, Adrian Farrel wrote:
>>>1. I don't understand the gmplsTunnelLinkProtection whose function is
>>>described in RFC3471.  Since this document describes the MIB to
>>>configure the field it probably shouldn't be an issue for this document.
>>>However it would be good to know if the authors considered any
>>>additional security considerations associated with this variable.
>>
>>"Protection" here refers to the establishment of a secondary LSP that can
>>be used to carry the traffic in the event of the failure of the primary
>>LSP. It is not related to the Security use of the same term.
>>
>>For more on GMPLS protection terminology you can read RFC4327.

===

Dan Romascanu - Discuss

> ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module 
> under
> transmission. That seems weird. By convention, transmission assignments 
> generally
> correspond to ifType values, which would result in a "Relationship to the 
> Interfaces
> MIB" section of the document.  If they don't define a new ifType value, I 
> don't see
> why it should be under transmission.  If, on the other hand, this is 
> intended to be the
> MIB for ifType = mpls (166), then it should have a "Relationship to the 
> Interfaces
> MIB" section. I think it would be better to put this under the mib-2 tree 
> or under the
> mplsStdMIB tree


After discussion, we determine that the module in question is 
IANA-GMPLS-TC-MIB.

We agreed that this module should be under the mib-2 tree. The document has 
been updated accordingly.

===





Envelope-to: [e-mail]
Delivery-date: Tue, 05 Sep 2006 23:17:37 +0000
Message-ID: <0fd801c6d141$3bf4dba0$89849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: New WG I-Ds
Date: Wed, 6 Sep 2006 00:14:00 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi,

I asked about...

> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt 
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-03.txt 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt


draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt generated some constructive 
comments that the authors can factor into the next revision. There appears 
to be good consensus for this draft.

Authors, please submit draft-ietf-ccamp-gmpls-vcat-lcas-00.txt with no 
changes except the name and the date. You must wait for the -01 revision to 
address the comments that you have received.



draft-caviglia-ccamp-pc-and-sc-reqs-03.txt generated a huge amount of 
discussion. While there was a lot of support, there were also quite a lot of 
concerns raised, and that means I do not see consensus at the moment. 
However, I think I can see a way forward here, but I need to send a summary 
of the debate to the list to see if we can reach some consensus. Authors, 
you must wait before doing anything with this I-D.



draft-ali-ccamp-mpls-graceful-shutdown-04.txt received some comments that 
will need to be addressed. Most of these can be left to the next revision, 
but one change must be made now, the I-D must go onto the Informational 
track.

Authors, please submit draft-ietf-ccamp-mpls-graceful-shutdown-00.txt 
changing only the name, date, and intended status of the draft. You must 
wait for the -01 revision to address the comments you have received.





Envelope-to: [e-mail]
Delivery-date: Tue, 05 Sep 2006 14:52:03 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-automesh-02.txt 
Message-Id: <[e-mail]>
Date: Tue, 05 Sep 2006 10:50:01 -0400

--NextPart

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		: Routing extensions for discovery of 
                          Multiprotocol (MPLS) Label Switch Router
                         (LSR) Traffic Engineering (TE) mesh membership
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-automesh-02.txt
	Pages		: 15
	Date		: 2006-9-5
	
The set up of a full mesh of Multi-Protocol Label Switching (MPLS)
Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
Label Switch Routers (LSR) is common deployment scenario of MPLS
Traffic Engineering either for bandwidth optimization, bandwidth
guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment
may require the configuration of potentially a large number of TE
LSPs (on the order of the square of the number LSRs).  This document
specifies IGP routing extensions for ISIS and OSPF so as to provide
an automatic discovery of the set of LSRs members of a mesh in order
to automate the creation of such mesh.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-automesh-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-automesh-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-automesh-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-automesh-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Sun, 03 Sep 2006 18:01:07 +0000
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 3 Sep 2006 19:59:00 +0200
Content-Type: text/plain; charset="US-ASCII"

question about this doc - section 4 (where the real story starts)

"If the loose next-hop is not present in the TED, the following
   conditions MUST be checked:

   - If the IP address of the next hop boundary LSR is outside of the
   current domain,

   - If the domain is PSC (Packet Switch Capable) and uses in-band
   control channel

   If the two conditions above are satisfied then the boundary LSR
   SHOULD check if the next-hop has IP reachability (via IGP or BGP)."

what if one of these condition doesn't hold (?)

in the following case X --- [ASBR1 -...- ABR1 -...- ABR2 -...- ASBR2] -- 
[ASBR3 --..-- ASBR4] 

ASBR1 receives ASBR4 [loose], the IP address of the so called "next hop 
boundary LSR" is inside the domain if we refer to the AS but within domain 
if referring to the Area => the draft says "current" domain ... what does 
it mean ?

ABR1 is locally known to ASBR1, ASBR4 (loose next hop) is outside domain 
... does that generate any failure ? i don't think so 

if authors/others could clarify ?

ps: on the structure of this doc - if section 3 could concentrate on 
working assumptions and put examples (and other tutorial material) in 
appendix this would be helpful in facilitating reading

-d.




[e-mail]
30/08/2006 21:50
Please respond to internet-drafts
 
        To:     [e-mail]
        cc:     [e-mail]
        Subject:        I-D 
ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.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                           : A Per-domain path 
computation method for 
                          establishing Inter-domain Traffic 
                          Engineering (TE) Label Switched Paths (LSPs)
                 Author(s)               : J. Vasseur, et al.
                 Filename                : 
draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
                 Pages                           : 21
                 Date                            : 2006-8-30
 
This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs).  In this document a domain refers to a collection of
network elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous
Systems.  Per-domain computation applies where the full path of an
inter-domain TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across domain boundaries.
This is most likely to arise owing to TE visibility limitations.  The
signaling message indicates the destination and nodes up to the next
domain boundary.  It may also indicate further domain boundaries or
domain identifiers.  The path through each domain, possibly including
the choice of exit point from the domain, must be determined within
the domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt


To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                 [e-mail].
In the body type:
                 "FILE 
/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".
 
NOTE:            The mail server at ietf.org can return the document in
                 MIME-encoded form by using the "mpack" utility.  To use 
this
                 feature, insert the command "ENCODING mime" before the 
"FILE"
                 command.  To decode the response(s), you will need 
"munpack" or
                 a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                 exhibit different behavior, especially when dealing with
                 "multipart" MIME messages (i.e. documents which have been 
split
                 up into multiple messages), so check your local 
documentation on
                 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[e-mail]/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce





Envelope-to: [e-mail]
Delivery-date: Sat, 02 Sep 2006 13:30:55 +0000
Message-ID: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>, "Ross Callon" <[e-mail]>
Subject: Routing Directorate comments on draft-ietf-ccamp-automesh-01
Date: Sat, 2 Sep 2006 14:25:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit

Hi,

We held an additional last call for this draft in the IGP working groups and 
received some further comments that JP has just addressed in a new revision.

We have also received some comments from a review in the Routing Directorate 
that I am précising below. JP, authors: please look through these and let us 
know your proposals for dealing with them.

Thanks,
Adrian

===

1) The Tail-end name field facilitates LSP identification. Is this a new 
form of LSP identification?
 If it is not new, then there should be a reference to RFC3209 and a 
statement of which RFC3209 fields are mapped to this IGP field.
If it is not new then there is a significant concern that a new 
identification is being introduced when it is not needed.

2) The document mentions that the number of mesh groups is limited but 
potentially (depending on encoding) provides for binary encoding for
 2^32-1 groups (although this might be constrained by OSPF's limit of a TLV 
size to 2^16 bytes.
The document (and the authors) state that scaling of these extensions is not 
an issue because only a small number of mesh groups are likely to be in 
existence in a network, and any one router is unlikely to participate in 
more than a very few.
There are two concerns:
a) Whenever we say that something in the Internet is limited, history 
usually proves us wrong. Indeed, there is already a
 proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a similar 
mechanism for a problem that would have far more groups.
b) The I-D does not itself impose any reasonable limits on the number of 
groups with the potential for a single router (by misconfiguration, design, 
or malice) advertising a very large number of groups.
Thus, it appears that the scaling concerns are not properly addressed in 
this I-D.

3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL and must at 
most appear once in a OSPF Router Information LSA or ISIS Router Capability 
TLV." but for addition/removal it mentions "conversely, if the LSR leaves a 
mesh-group the corresponding entry will be removed from the TE-MESH-GROUP 
TLV."
What are these "entries" referring to - that there is a top-level 
TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions "No 
sub-TLV is currently defined for the TE-mesh-group TLV") ?

AF>> My comment on this is that the definition of the TLVs seems unclear.
AF>> From figure 2, it appears that some additional information can be
AF>> present in the TLV after the fields listed, and (reading between the
AF>> lines) it would appear that this additional information is a series of
AF>> repeats of the set of fields to define multiple mesh groups.
AF>> This could usefully be clarified considerably.
AF>>
AF>> But it is now unclear to me whether a single router can be a member
AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be
AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one
AF>> IPv6) are prohibited.

4) Small terminology issue in section 5.1 it says: "Note that both 
operations can be performed in the context of a single refresh."
This is not a refresh. It is a trigger/update. A better term for OSPF would 
be "LSA origination".

5) Please state the applicability to OSPF v2 and or v3. Note that the 
Router_Cap document covers both v2 and v3

6) The term "fairly static" at the end of section 5.1 is meaningless without 
some relative context.
Presumably this relates to the number times an LSR joins or leaves a mesh 
group over time.
Is it intended to be relative to the IGP refresh period?
Please clarify in an objective rather than a subjective way.

7) The security section (section 8) is inadequate and will undoubtedly be 
rejected by the security ADs. At the very least, the I-D needs a paragraph 
(i.e. more than one or two lines) explaining why there are no new security 
considerations. But what would be the impact of adding false mesh groups to 
a TLV? Is there anything (dangerous) that can be learned about the network 
by inspecting mesh group TLVs?






Envelope-to: [e-mail]
Delivery-date: Fri, 01 Sep 2006 07:07:11 +0000
Message-ID: <08ee01c6cd94$fe01e9f0$89849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt 
Date: Fri, 1 Sep 2006 08:04:53 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi CCAMP,

This revision addresses further IESG concerns with the security section. At 
this stage we believe that the I-D will now pass muster at the IESG and go 
forward to the RFC Editor.

Cheers,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, August 31, 2006 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.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 : A Framework for Inter-Domain Multiprotocol Label Switching Traffic 
> Engineering
> Author(s) : A. Farrel, et al.
> Filename : draft-ietf-ccamp-inter-domain-framework-06.txt
> Pages : 21
> Date : 2006-8-31
>
> This document provides a framework for establishing and controlling
>   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
>   Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain
>   networks.
>
>   For the purposes of this document, a domain is considered to be any
>   collection of network elements within a common sphere of address
>   management or path computational responsibility. Examples of such
>   domains include Interior Gateway Protocol (IGP) areas and Autonomous
>   Systems (ASs).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-ccamp-inter-domain-framework-06.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>